I’m thinking of making a change to the way Cantabile prompts to save song files. Currently the model follows very closely the standard Windows document model where you have an open document (the song), and if you move to another document it prompts you to save.
I’m starting to realize this isn’t a good solution for Cantabile…
The Problem
The VST spec doesn’t include a concept of a “modified plugin”. Cantabile guess this by watching for parameter changed notifications, but it’s far from perfect: insiginificant changes in a plugin will often cause the song to be marked as modified when it shouldn’t and major changes in a plugin might fail to mark a song as modified when they should.
If you’re not at the computer where Cantabile is running or if running on a headless machine, prompting to save a changed song is problematic.
Number 2 is about to become a bigger problem with the new network server API that I’m (still) working on.
Proposed Solution
So I’m thinking of changing things so that songs can be closed, without being saved and without losing any changes. This will work as follows:
When you close a song (or Cantabile) you won’t be prompted to save changes
When you re-open a song that was modified, it will come back in its exact same state and will still be marked as modified.
To “go back” to the last saved version you use the File -> Revert command.
If you have a song that you want to keep locked down to a specific version and never save transient changes then you can set File -> Song Options -> Mark Song Modified -> Never. (although that option could probably be replaced with something similar if I introduce these changes)
How it Works
The song file will internally store two copies of the song - the working copy and the saved copy
When you explicitly save a song file (ie: File -> Save or Save As), the saved copy will be updated from the working copy and the file written to disk.
When a modified song is closed, the file will be rewritten to disk, with the working copy storing the song/plugins in their current state and the saved copy will be maintained from how the song was when it was loaded.
When a song is reverted (File -> Revert) the working copy is discarded and replaced with the saved copy and then the file is reloaded.
Cons
Files with working and saved versions will typically be twice the size
Possible impact on song unload time as the song will always need to be written to disk (I think this will be negligible and would be surprised if anyone notices a change here)
Non-standard convention that new users might not immediately grasp (although I have seen a similar approach in some other apps now eg: Sublime Text)
Other Benefits
If Windows wants to reboot due to update or for some other reason, Cantabile can cleanly shutdown and come back to where it was. Same if Cantabile needs to restart due to a significant change in Options.
Solves issues around prompting to save when switching songs via bindings and via the new network API.
Same mechanism could be used to store multiple previous versions of a song.
Same approach would be used for set lists (and possibly racks)
I already disable the Prompt to Save option precisely because I usually don’t want to save those transient song changes that I make when playing live. I may occasionally forget to save the song manually, but not too often. So this new feature would be fine with me (some extra benefit, no real downside), but something I already work around.
I am careful to save manually but this could save me when i shut down and forgot to save. I could correct the next time I came back. That appeals to me anyway and if it applies to the set list and the racks even better. The cons don’t seem problematic for my uses so … I’d say go for it!
Sounds good to me, but I’m concerned about what would happen if racks were included in this mechanism. If I have unsaved state in a rack in one song, and that gets saved, would that state get restored if the rack is then loaded in a different song? If so, that probably wouldn’t be desirable.
Thanks for the feedback everyone. I’m still thinking through the details on this, but seems like it might be a workable solution.
I’m not 100% sure how this would work yet, but I think this change would basically make racks behave the same across a set list regardless of whether pre-loading is turned on or not. ie: loading and unloading a rack would restore it to its saved state and then do a rack reset - just like when moving between songs when set list pre-loading is turned on. You’re right though, this will need some thought and perhaps a way to tweak the behaviour.
Yes, but not every DAW is remotely controllable for song switching which is where this does become a problem. This probably isn’t a huge problem, but perhaps only because it can be worked around by tweaking Cantabile’s settings to either always/never save. I’m just trying to find a better solution.
The reason I want to address this now is because of the new Web UI which makes it a more pronounced problem… eg: suppose you’ve got the Cantabile running on a headless machine “out the back” and you’re controlling it from you tablet. You click in the set list to load a different song and Cantabile displays a “prompt” but you can’t see it, nor respond to it and the web UI basically stops working.
Headless use is, I would venture, a useful facility for playing live.
Playing live? Turn off all save prompts.
Programming your Cantabile? You’re probably not running headless.
Have I missed something here?
But if you don’t know to do this, or you forget, then things quickly fall apart.
The other possibility that I’ve been thinking about is if the request to switch songs comes from the network api then just always save or always discard (ie: no option to prompt).
That sounds like a good idea. But the same should maybe also apply if the request to switch songs is coming from a binding. I don’t run Cantabile headlessly, but the computer is way out of reach while I’m playing live, and I switch songs using a footswitch. So in this scenario, the requirements are identical to the network case.
OK - thanks to @Ade’s devils advocacy, I’ve decided against this change for now and instead just never prompting to save when the song switch command originates remotely - ie: via binding or via network.
Yes! The old option to prompt on song switch via MIDI has been changed to only allow Yes/No and updated to reflect that fact that it affects MIDI and Network:
@brad - Could we at least bring back the “Prompt” option for MIDI song change? Using a MIDI controller to select songs to walk through an upcoming show, i might tweak something in e.g. Show Notes and need the option of whether or not to save changes when i go on to the next song.
When do you absolutely NOT want saving to take place?
And if something is important enough to save - or important enough to NOT want to save, it may be best to learn the good practice of having to specifically turn saving options on or off, or just use the key commands to update/ save any edit without changing the pref.
Here’s my primary concern:
What’s more disastrous? Having your live show hiccup?
I was thinking this too, but not sure everyone runs in live mode and I’m a little reluctant to start making behaviour changes between live mode and normal mode - at least not changes that are somehow obvious.
I mostly agree with this. Perhaps there just needs to be an easier way/more obvious way of switching between save/nosave.
Let me think about it some more but having prompts appear in any sort of remote control situation where the UI isn’t visible really does open one up to loss of control.
