• Date
    alistermorton
  • Date
  • Replies 19 replies
  • Subscribers 193 subscribers
  • Views 9679 views
  • Users 0 members are here

Feature request - autosave

Following a discussion on another forum, the issue of autosave came up. Many consoles automatically save the current show as it is being edited, keeping incremental copies (as would happen if you hit shift-Update every 5 minutes, say). Would it be a useful feature to allow autosave to be turned on so that after some configurable period the desk has unsaved changes the desk automatically saves it, and if a different show is loaded when the current show has unsaved changes then the current show is autosaved. Obviously it should be configurable how autosave works and how often often. I'd suggest options to switch on/off

1) saving unsaved edits after a configurable period

2) saving unsaved edits before loading a different show

3) Whether to prompt before autosaving on loading a new show.

Thoughts?

Parents
  • while i generally like the idea, at the moment saving a showfile will clear the undo list and i wouldn't like this to happen without me controlling it...
  • in reply to ueliriegg
    Not to mention that the operator wants to be saving at a moment in the cueing process when the LD isn't calling commands. As well, when using multiple consoles, saving is a process that affects ALL consoles, thus the different operators all need to be a pause when a save is run. I also save to the thumb drive after saving to the HD, which an autosave might not do. SO I think this is one of those functions that the operator needs to know to do and should remain in control over.
  • in reply to Steve Bailey

    Very valid points, and why it should be configurable and under the control of the operator. The consensus on the other forum was that other freelance LDs found it useful to have autosave on their consoles and wondered when ETC were going to offer the option.

  • in reply to alistermorton

    Autosave was in the initial development specification.   We decided not to do it because of the lack of control and the propensity to save at inopportune times.    We do discuss it periodically and it may go back on the list (as an option, because many people would hate it).  When a save is generated, all HD's on the system are impacted.   Until we make a decision to put it on the list, we are going to do the following:

    1)  In 2.3, the browser will represent files that will change persistent storage in a different color.  Despite the indicator at the top of the browser as to which tool you are in (open, save, merge, etc), we still get complaints that people open files when they meant to save files.   So this is intended to help with that.

    2)  We will hold the undo buffer through at least 2 save cycles.

    3)  We have a requirement written that if you use the open feature and there is unsaved data in your current show file, we will post an advisory with a confirmation to save before opening the new file. 

    At some point, setup will be restructured to break functions into system settings (and this would have to be a system setting), user settings and desk settings, with all options saved and restored to all system devices accordingly.  If we add autosave, the time to do it would be when setup is redesigned.

    Thanks much!

    Anne

  • in reply to Anne Valentino
    Thanks, Anne, useful reply. I have a feeling that the people who were commenting on the other forum tend to use consoles which are stand alone and not part of linked systems. In that instance the impact is smaller and more easily managed on a personal level.
  • in reply to Anne Valentino
    Hi Anne. Thanks for all this. 2 thoughts, related to this thread: 1) in the browser, I appreciate any changes that would clarify between the Open folders, Save folders, and Merge folders. I'd also love to see a graphic change that differentiates better between a show folder, and a single show file. they look the same, except that the show file has a longer non-text extension (date and time code). A folder graphic at the leading edge of the folder would be wonderful. 2) consider this scenario for the auto save functionality: road house with a house plot. each day starts by Opening the house show file. IDEALLY the electrician will save that day's show into a client folder somewhere. (I wish my electricians would do that consistently) However, I would hate any autosave function to save a "new" show into my existing house show file that I don't want changed on a daily basis. either some way of write-protecting existing show files, or a Save dialogue box that says Save this show, UNDER a NEW FILE NAME. something strong that an "Are you sure . . ." type box. Andrew Riter
  • in reply to Andrew Riter

    Somewhat puzzled by all this.

    You can create folders within the Show Archive folder that should clarify where files should live. I have Basic (templates and house files), Current, Upcoming and Old, which has it's own folder substructure for seasons. I do routinely file manage in the shell to keep this all cleaned up, as well I keep after the operators to store correctly. Thus I potentially have fewer issues then you run into.

    As well, all file saves are new, not overwriting older files, so you always have protection against inadvertent saving, provided the operator is not being stupid and placing the file in some obscure folder in the Show Archive. And the show file has a different name - Yes ?, so no chance of saving a file called "Annie" over the "House Basic". The desk won't allow that.

    As to AutoSave (as currently done on the Eos system) -  I'm firmly against it. I think some functions need to be learned by all operators as basic operations that need to be routinely followed, backing up to multiple thumb drives as example (and not leaving all of them sitting on the desk at the close down !). They have to learn other functions - turning on USB devices before the desk, doing lamp check, etc.... and saving routinely and getting in the habit (every half hour is my rule) is part and process to being an operator. I do not want to automate that, I want them engaged in what they need to be doing on the desk. That's the whole point of having a console operator and if the LD or theater doesn't want that, then give them a laptop and a Nomad.

    If an Auto-Save was a background function and did not stop other processes and functionality, then I'd be OK with it.  

  • in reply to Anne Valentino
    I too have been thinking about this for a while and agree it should be a user defined parameter. Simply, or maybe not programming simply, but a check box in settings that either allows it or not. Then it's completely up to each user. What I have also wanted is the ability to select the it's a done deal when making changes in blind. Working on the fly and making changes to an already existing show that won't need to remain is something I would rather not have. I know most have wanted and appreciate that feature in Blind but I would also rather be able to check a box to do that or not. It might be to big a deal to go through by the programmers for the few that may want it so I understand but if it's a fairly simple thing then maybe? :-) As the original author has mentioned several times, make these things user selectable. A lot of voices have been heard why some don't like the suggestions but they would be the ones who check the boxes accordingly and are done with it.
  • in reply to Steve Bailey
    [quote user="Steve Bailey"] Somewhat puzzled by all this. You can create folders within the Show Archive folder that should clarify where files should live. I have Basic (templates and house files), Current, Upcoming and Old, which has it's own folder substructure for seasons. I do routinely file manage in the shell to keep this all cleaned up, as well I keep after the operators to store correctly. Thus I potentially have fewer issues then you run into. I have sub folders for different clients and events as well. Yes, it's a local issue to get the house board op (the only electrician in the building for a rental call) to save-as the house show file as a different show name. I'm less concerned about getting the show file in the exact correct spot (since chances of actually ever using it again is nearer None than Slim) than the board op not even saving his show once. As well, all file saves are new, not overwriting older files, so you always have protection against inadvertent saving, provided the operator is not being stupid and placing the file in some obscure folder in the Show Archive. And the show file has a different name - Yes ?, so no chance of saving a file called "Annie" over the "House Basic". The desk won't allow that. True. Nothing is over-written. Save will write a new file with the same show name. Yes the original file isn't corrupted, but when I next open the "basic house file," which will be the file at the top of the list of all the previous versions, it won't be the house file, it will be a corrupted file. I've done this myself up Updating the show file without first Save-as a new show name. You can save the Annie show, but it's called the House patch. so when I go to open the house patch, I get Annie. I then need to figure out when the bad electrican started updating the house patch with the Annie data. Andrew
Reply
  • in reply to Steve Bailey
    [quote user="Steve Bailey"] Somewhat puzzled by all this. You can create folders within the Show Archive folder that should clarify where files should live. I have Basic (templates and house files), Current, Upcoming and Old, which has it's own folder substructure for seasons. I do routinely file manage in the shell to keep this all cleaned up, as well I keep after the operators to store correctly. Thus I potentially have fewer issues then you run into. I have sub folders for different clients and events as well. Yes, it's a local issue to get the house board op (the only electrician in the building for a rental call) to save-as the house show file as a different show name. I'm less concerned about getting the show file in the exact correct spot (since chances of actually ever using it again is nearer None than Slim) than the board op not even saving his show once. As well, all file saves are new, not overwriting older files, so you always have protection against inadvertent saving, provided the operator is not being stupid and placing the file in some obscure folder in the Show Archive. And the show file has a different name - Yes ?, so no chance of saving a file called "Annie" over the "House Basic". The desk won't allow that. True. Nothing is over-written. Save will write a new file with the same show name. Yes the original file isn't corrupted, but when I next open the "basic house file," which will be the file at the top of the list of all the previous versions, it won't be the house file, it will be a corrupted file. I've done this myself up Updating the show file without first Save-as a new show name. You can save the Annie show, but it's called the House patch. so when I go to open the house patch, I get Annie. I then need to figure out when the bad electrican started updating the house patch with the Annie data. Andrew
Children
  • in reply to Andrew Riter

    Andrew Riter said:
    I then need to figure out when the bad electrician started updating the house patch with the Annie data

    Not if you load your house patch/default show file from a USB Stick. And on the USB stick you can make it read only  as well....
    And NO I don't ever want Autosave! I want to decide when to save, I might just play around and try a few things and bang the desk saves things for me I don't want. In order to be trusted to sit behind a lighting desk one should understand a few basic principals, one of them is to save your work regularly.  If you can't remember to save you will pay the price eventually and you will learn your lesson and never ever forget to save again!

    Just my 2P

  • in reply to FloBaeumler
    as i cannot resist a robust discussion i will add my thoughts as well. I am not a fan of auto save personally as it does clear the ability to undo, though keeping the buffer through 2 cycles will be a welcome feature. I agree 100% with the need for it to be an operator function and i, working in a college environment stress the importance of saving with all our new programmers. I honestly would not see me using it personally but, how many elements and ion's are in K through 12 environments. were you have an instructor that relies on a student to figure out how it works or fumbles through on their own. I see merit in having the ability to turn it on and off. It is easy enough to store a default show with your desk and show settings . I know there is a lot of resistance to having a lot of configurable options for the desk , but the fact is we all do things different and having the ability to do things the way that makes sense to the user seems a better option. the mere fact that we are having this discussion shows the need consider this as option.
  • in reply to ehuber
    I could see an auto-save feature that would function the same as Shift-Update, only on power down. This would at least save the last edits to the HD and would be useful for schools, etc...
Related

www.etcconnect.com