Page 1 of 1

Proposed change to 'save' processing (in 10.1.0)

Posted: Wed Mar 12, 2008 5:37 pm
by Mike Daniell
For SCS 10 I am planning to modify the way changes made in the editor are saved to the cue file, and I welcome comments on this proposed modification.

In SCS 9 when you close the Editor you are asked if you want to save changes, and if you reply 'No' then the changes you made since the last save are rolled back.

The modification I am planning for SCS 10 is to only ask you if you want to save changes if you have unsaved changes when you are about to close the whole program (or open another cue file). You would therefore be able to open and close the Editor as often as you wish and your changes will not be rolled back.

There will be some other new features to support this change. Firstly, there will be a Save / Save As facility in the the Run Screen (as well as in the Editor), so it will be easy for you to save changes whenever you wish to.

Secondly, there will be an auto-save feature. At a user-defined interval (default 10 minutes) SCS will save to a recovery file the latest state of the cue file, plus some details of the current cue, etc. When SCS is started it will look for the recovery file and if found will ask you if you want to recover from that last session. (The recovery file is removed when you save or discard your changes.)

Thirdly, you will be able to Undo/Redo changes you make in the Editor. This will replace the Revert button. With Undo you will be able to undo individual field changes, etc, which is much more useful than the action of the Revert button.

Any comments or other suggestions on this proposed modification?

New save feature

Posted: Wed Mar 12, 2008 7:19 pm
by n4j
Hi Mike,

You seem to have covered all the bases with your proposed changes. I think the ideas you have for this are excellent. Could it be made configurable in some way, such that if you check a box for "SCS9 save prompt compatibility" (probably not a very good name for it...) then it will do the same as SCS9 does at present.

Re: Proposed change to 'save' processing

Posted: Wed Mar 12, 2008 7:24 pm
by dee99
That sounds much more useful.
The modification I am planning for SCS 10 is to only ask you if you want to save changes if you have unsaved changes when you are about to close the whole program (or open another cue file). You would therefore be able to open and close the Editor as often as you wish and your changes will not be rolled back.
I would suggest that SCS10 offers the option of offering the option of a SaveAs or a SaveCopy at this point.

:idea: The other thought I had was to offer a SaveVersion which saves a latest copy with a version stamp in the file name and/or in the file plus a field for version comments. This way users can revert to previous versions easily and remember what it was they changed & why.

Dee99
In /dev/null no one can hear you scream...

Re: Proposed change to 'save' processing

Posted: Thu Mar 13, 2008 6:36 am
by sound
Mike Daniell wrote:Thirdly, you will be able to Undo/Redo changes you make in the Editor. This will replace the Revert button. With Undo you will be able to undo individual field changes, etc, which is much more useful than the action of the Revert button.
Will it be a 'Undo-list' as in SF or Nuendo? If not then the Revert button would still be useful.

Greetings,
Walter

Re: Proposed change to 'save' processing

Posted: Thu Mar 13, 2008 4:10 pm
by Mike Daniell
Yes, it will be an 'Undo' list. On clicking the 'Undo' button you will see a list of recent changes, and you will be able to undo multiple consecutive changes with one click. Each action in the list is preceded by the cue number or other qualifier, so you can easily see which changes affected the cue you are currently editing. Same applies to 'Redo' - that has the same list.

Re: Proposed change to 'save' processing

Posted: Thu Mar 13, 2008 4:14 pm
by Mike Daniell
Dee99 wrote:The other thought I had was to offer a SaveVersion which saves a latest copy with a version stamp in the file name and/or in the file plus a field for version comments. This way users can revert to previous versions easily and remember what it was they changed & why.
I'll look into providing an option for this as it has been requested before.

Re: New save feature

Posted: Fri Mar 14, 2008 8:22 am
by sound
n4j wrote:You seem to have covered all the bases with your proposed changes. I think the ideas you have for this are excellent. Could it be made configurable in some way, such that if you check a box for "SCS9 save prompt compatibility" (probably not a very good name for it...) then it will do the same as SCS9 does at present.
What for?
IMHO the new features are a big improvement - why would anyone want to use the old settings?
Greetings,
Walter

Re: Proposed change to 'save' processing

Posted: Fri Mar 14, 2008 8:51 am
by jkowtko
Mike, if you really wanted to provide a switch, I would not call it "SCS9 compatibility mode" ... I would suggest calling it something like "Edit/Save Scope" with the choices of "editor only" or "editor and run-time"

Re: Proposed change to 'save' processing

Posted: Fri Mar 14, 2008 9:09 am
by Mike Daniell
jkowtko wrote:Mike, if you really wanted to provide a switch ...
Actually, I'd rather not provide a switch. With some functions it's better to provide a single solution that everyone uses. The consensus seems to be very much in favor of the proposed changes, which is good.

One minor change to the specification: I mentioned the default time for saving the recovery file would be 10 minutes. I'll actually make that far more frequent as it is a very fast operation. I'll run some tests, but I may check every 10 seconds if the recovery file needs to be saved, provided you're not currently dragging a level slider or something like that. It would not therefore be necessary to provide a user-defined interval for saving the recovery file.