just a clarification question on this option: currently, when I save a song, all modified racks automatically get saved as well. Does setting the modified file behavior to “never” now mean that these racks will not be saved with the song when I select “save song”? So the only way to save them is to enter the rack for editing and then press “save rack” - correct?
If so, then this is a great step forward for me; with all my controller bindings, most racks get modified a lot, and this often makes debugging a bit tedious.
Still, for everyone using MIDI controllers to modify parameters in their racks, my default solution remains valid and important: for every parameter in a rack that I control via a binding, I set up a song state trigger that sends the respective controller to the rack. This way, I have a well-defined state of the respective parameter (leslie speed, volume, reverb volume) at the beginning of every song state (unless I need changes to carry over across song states, in which case I simple de-activate the trigger for the respective state.
Hi Torsten, Brad,
I guess the menu command “save all” is made to avoid mistakes when working with racks. But I’m have no clear what things saves that command and what not. Can you explain me?
The Song file is always saved - regardless of modified. If currently unsaved, filename is prompted.
Any rack referenced by the song are saved - only if modified,
If the Set List contains any songs the set list is saved - regardless of modified. If currently unsaved, filename is prompted.
The background rack - regardless of modified
Any other songs and racks that are loaded due to set list pre-loading are saved - only if modified.
Any by modified - I mean if the file is marked as modified according to the Modified Behaviour in the files options.
@torsten One of the things I hope to be implementing soon is rack state reset - which is like a fast version of loading a state where plugins aren’t reloaded but all other state settings and plugin parameters are reset. I think this should eliminate much of the need for bindings/triggers. The idea is that whenever a song or rack state is loaded - even if it’s the same state as the currently selected one then the file is “reset” to its original state.
However, this would have a negative affect on this:
Is this a common/actual requirement? If so - is it a per rack setting, or I imagine it’d be more based on two particular songs in sequence. Open for suggestions/comments on this but sounds like I might need to make the above described reset behaviour optional/controllable.
quick example for a change carrying over across song states: I have a string layer (in a separate rack!) where I modify the rack volume via a controller (sends CC7 to the rack). At the beginning of the song, I usually set the string layer volume with a trigger (send CC7 with the appropriate value to the rack). Usually, I actually have this trigger with every song state, to make sure that e.g. I have the right string level at the beginning of the chorus. For this, your rack state reset would come in handy.
In some songs, however, I set the string level manually and then I may change the piano sound for the chorus but will want the string layer to stay at the manually adjusted volume. This is where I currently just de-activate the trigger for the chorus state (and for any following state - so no linked states to the first one…).
So, for this kind of situation with state reset in place, I guess the easiest way would be to have a setting at rack level “reset rack at state change” which would be on by default and off for this specific situation.