This past week I’ve been working on some changes on how song and rack saving works. Here’s a little sneak peek at what’s in store:
The biggest change is when set list pre-loading is turned on you’ll no longer be prompted to save changes when switching between songs in the set list. The songs are just kept loaded, possibly marked as modified.
When set list pre-loading is on, modified songs are indicated in the set list:
When turning off set list pre-loading, or deleting pre-loaded songs from the set list, or closing a pre-loaded set list, (ie: any operation that causes a pre-loaded, modified song to be unloaded) you’ll be prompted to save those modified songs and given the chance to choose which songs to save, or to cancel…
you can prevent this prompt with this setting:
When switching between two pre-loaded set lists, all songs in the old set list will be unloaded (after being prompted to save) and reloaded from disk if also referenced in the new set list. Racks common to both set lists will be kept loaded and not need to be reloaded.
You’ll no longer be prompted to save racks (you kind of were before, but not really). Rather, rack saving is controlled by a new (actually renamed and tweaked) setting:
(I’m also considering reducing this to just Always / Never)
If you have a rack set to never save, you can always explicitly save it via the File | Save menu
If you have a rack set to always save and you make a mistake and want to discard the changes there’s a new menu command File | Revert Rack. There’s also File | Revert Song when editing songs
Explicitly saving a song will also save any referenced racks according to the save on unload setting.
Invoking Save All will save:
any pre-loaded, but inactive racks according to the save on unload setting
any modified pre-loaded songs
the set list if modified
This “Always save when saving parent Song” setting has been removed. For racks that had this option turned on, this will be converted to the “Save Rack: Always” setting.
Of course please speak up if you see issues or have concerns with any of this.
ad point 5:
I think those options could be confusing, as we don’t know what a “significant change” is f.e.
So IMHO Never/Always is enough!
(also “always” and “on change” is kind of the same, isn’t it?)
My thoughts as well. I think the options beyond always/never are fairly esoteric (and the definition of “significant” is pretty arbitrary ) Although you could maybe keep those options and hide them in an “advanced options” menu, probably unnecessary.
And what is the difference between “on any change” and “always”?
Those options are basically what’s already there. Always and On Change aren’t the same because sometimes a plugin can change and not notify the host. Always would always save and always capture those changes. On Change wouldn’t because Cantabile wouldn’t know something in the plugin has changed and therefore not save it.
I tend to agree though - it’s pretty arbitrary and always/never might be better for racks.
Having a “never save” sounds sort of intensely negative… almost like it would override your attempt to save manually. I suppose most people would get the right idea but maybe it should be always save / prompt to save / don’t prompt.
Actually, from what I can tell how many people use racks is this is actually exactly what they want… they’ve got the rack setup how they like and never want it accidentally changed. It’s labelled as “Save Rack on Unloading” to reinforce this is just what will happen automatically if you don’t explicitly save it. Maybe it would be better “On unloading rack: Save/Discard”
I’ve tried a number of ways to make prompting to save racks reasonable but it’s all too messy - partly because it’s kinda tricky to figure out when a rack is going to be unloaded. eg: consider switching between two pre-loaded set lists - it would need to figure out upfront which racks will be unloaded, prompt to save them (giving the chance to cancel/abort) before actually starting the unloading of one set list and loading the next.
I feel like this ability to set how the rack will be saved when it’s no longer in used is cleaner/simpler.
I could not count the many times, especially on stage, I have accidentally changed a rack, only to discover the change in the next set list or on another gig. I am one that has my rack setup like I want, and through my apparent confusion on the save or not to save, I have had too many “OH NOOOOO!” moments. Many late nights at home berating myself as I search for my mistakes.
Well that to me is why you want a lock option. I really think you should be able to lock songs as well as racks… so I guess the “never save” is like that but I think the idea to implement locks (and corresponding icons) is better.
It may be better that way. There is no doubt, it is somewhat confusing to me, but even though I work my setups at home or rehearsal where there is time, I seem to always discover my mistakes at gigs, where my partners in crime turn to give me that “look” of computer hate.