I’m considering making a change to the way rack states are loaded that might impact some existing saved setups. The reason for the change stems from the issue described here.
The problem was related to exported state behaviours and the way they interact with state switches on the rack. Until now exported states work by merging the exported state over the rack’s saved state and the finally merged state is then loaded onto the rack. The problem here is when switching states directly on the rack, the exported song state doesn’t get re-captured causing the old exported state from the song to be reloaded into the rack and wiping out the just changed setting.
The fix I’m proposing is to only merge the exported state when switching states on the parent song or when switching the song itself. In other words, when switching states on the rack directly (either via a binding, or by the popup in the GUI) the exported state in the song is ignored and such a state switch will only affect properties for which the normal state behaviour is selected.
This change should be benign for most users except possibly in one case: when you have both the exported state behaviour and the normal state behaviour selected (ie: both checkboxes selected).
In this case:
When switching states directly on the rack the value saved in the rack will be used.
When switching states externally (by switching songs, or song state) the value exported to the song will be used.
Obviously I’m somewhat hesitant to make a potentially breaking change like this, but I think it’s the best fix as it most closely matches conceptually how state behaviours are presented and understood.
Considering how this change will affect users who checked both, the exported and normal state behavior of parameters inside a specific rack, I’ve just made a short test in the style of my preceding bug description. As follows…:
Step 1 to 7 as before:
New Song; New Linked Rack with only Exported State checked; Adding Plugin inside rack and unchecking all its State Behaviors; Creating two Rack States
New steps for this test:
08. Check both (!) state behaviors for the plugin (exported/left & normal/right “Run and Bypass Mode”)
09. Going to rack state 2 and bypass the plugin and back to rack state 1 with unbypassed plugin
10. Save rack
11. Save song
TEST 1:
Switching to rack state 2: Plugin bypassed OK
Switching back to rack state 1: Plugin unbypassed OK
Next steps:
12. Save all, close song and reopen it
TEST 2:
Switching to rack state 2: Plugin unbypassed ERROR!
Switching back to rack state 1: Plugin unbypassed OK
So the same bug appears in a different guise!
Conclusion:
I can’t imagine there is just one guy using exported and normal rack states parallel. This bug would have been uncovered earlier.
For example, after fixing this issue it would be possible to save your VSTi programs by rack states for fixed and reloadable Sounds. By parallel using exported states, you’d be able to amend this sounds song-/part-wise and unless you don’t save the rack, its states could be used as a reset. And further more. Awesome!
It sounds like a good fix for me, making the behaviour a bit more intuitive in my opinion. It would be interesting to know if anyone was actually relying on the current problematic behaviour.
