Proposed change to 'save' processing (in 10.1.0)
-
- Site Admin
- Posts: 3630
- Joined: Sun Jul 24, 2005 8:58 am
- Location: Brisbane, Queensland, Australia. TZ:GMT+10
- Contact:
Proposed change to 'save' processing (in 10.1.0)
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?
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
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.
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.
-=n4j=-
Re: Proposed change to 'save' processing
That sounds much more useful.
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...
I would suggest that SCS10 offers the option of offering the option of a SaveAs or a SaveCopy at this point.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.

Dee99
In /dev/null no one can hear you scream...
Re: Proposed change to 'save' processing
Will it be a 'Undo-list' as in SF or Nuendo? If not then the Revert button would still be useful.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.
Greetings,
Walter
-
- Site Admin
- Posts: 3630
- Joined: Sun Jul 24, 2005 8:58 am
- Location: Brisbane, Queensland, Australia. TZ:GMT+10
- Contact:
Re: Proposed change to 'save' processing
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.
-
- Site Admin
- Posts: 3630
- Joined: Sun Jul 24, 2005 8:58 am
- Location: Brisbane, Queensland, Australia. TZ:GMT+10
- Contact:
Re: Proposed change to 'save' processing
I'll look into providing an option for this as it has been requested before.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.
Re: New save feature
What for?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.
IMHO the new features are a big improvement - why would anyone want to use the old settings?
Greetings,
Walter
-
- Posts: 138
- Joined: Fri Jan 26, 2007 2:36 am
- Location: Redwood Shores, CA (SF Bay Area)
- Contact:
Re: Proposed change to 'save' processing
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"
John Kowtko
Sound Designer/Engineer
Local schools and community theater
Redwood City, CA USA
Sound Designer/Engineer
Local schools and community theater
Redwood City, CA USA
-
- Site Admin
- Posts: 3630
- Joined: Sun Jul 24, 2005 8:58 am
- Location: Brisbane, Queensland, Australia. TZ:GMT+10
- Contact:
Re: Proposed change to 'save' processing
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.jkowtko wrote:Mike, if you really wanted to provide a switch ...
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.