Cantabile build 4151 makes some changes to the way states are handled. The changes are subtle and you might not even notice the difference but this videos explains what's changed.
Excellent - thanx @brad! This makes my life so much easier…
Looks very subtle, but I really appreciate the work it took behind the scenes!
Thanks for your help and feedback. Big help.
That’s really great, to have it a bit more deterministic.
However I think I’m going to find myself very often replicating the old behaviour of “other states” having the new object disabled, by explicitly disabling it on all states then enabling it for the current state.
For example those situations where one song state of 20 needs an extra route, because it needs more keyboards splits than the other song states. With the new version, by default the other 19 states would be left with a dangling target, which would show up as a zone on the on-screen keyboard for all the other states.
So I wonder whether it might make more sense for new routes to follow the old behaviour of being disabled on all other states (but explicitly writing that into the states, for consistency). New objects like racks and plugins probably don’t make much difference either way.
Either way, great robustness enhancement!
Neil
Hey Neil,
Thanks for the feedback… I’ll have a think about it. In the meantime, just disable the route then use update all states to disable it everywhere else.
Brad
This is going to be such a time saver for me!
To me, it’s a matter of frequency: in over 95% of cases, I want a new route I’m adding to be active across all states. In those few cases where a route is to be active for one state only, I’d need three clicks more: de-activate the route; use “Update All States”, activate for current state - done! But across all my use cases, the new setup will save me time, clicks, and aggravation.
And regarding your use case of adding a route for one song state only, I personally would prefer to make that decision consciously and explicitly (“I want this route to be active for one state only”) instead of Cantabile making that decision for me.
But that may be specific to individual ways of working.
Maybe a new settings item “new routes only active in current state” in the “expert users” section?
But if “new routes only active in current state” becomes the new default, I’d just de-activate state behavior on routes by default; that way when I activate it, the current state will be propagate across all states, and I’ll be good as well…
Overall, the new state management definitely improves things!
Cheers,
Torsten
True, it’s good to make such decisions explicitly. But with the new behaviour, adding something on one song state will implicitly change all other song states. This is why I quite liked the original behaviour because if you add something to a state, you can be confident it won’t affect other states.
But yes, I’m sure it’s specific to everyone’s way of working, and the types of songs people set up. Many of mine have 20-30 states and some complexity in routing, and so I regularly need to put thought into complex state change behaviour. So for me, the less stuff that is changed implicitly in other states, the better.
Another example from my use cases involve a rack I have for doing expression pedal fades. It has a MIDI output which I then route to the rack I want to control the volume of, for fade ins/outs. It has rack states to choose between just fading, fading with an initial starting point, fading only 50% of the way, no fading, and so on. Typically I’ll add the rack, and on the song state where I need the fade, I’ll add a MIDI route to the target instrument rack. I know that on all other song states, that route is disabled, so won’t affect anything else - in particular any initial starting points that might change the volume unintentionally on state load. I sometimes need multiple instances of this rack, targeting different instrument racks, with different behaviours, such as one sound fading in while the other fades out. So with the new state management behaviour, in this kind of scenario, adding one of these expression pedal fade racks will be automatically actively routed to its target rack across all song states, which could break the intended behaviour of other song states, especially with an initial state-load setting. So I’d have to explicitly disable it for other song states in order to avoid breaking things.
That could work, and would then provide good defaults for both types of user. A third option could be “Always ask if new routes are active for just the current state or all states”, where Cantabile actually requires you to explicitly choose each time. This would be annoying for people who always one or other approach, but could be useful for those of us who might commonly use both in different circumstances.
It’s a very interesting problem, where different users have different use cases and expectations, and where there’s a need to make it clear what’s happening, but at the same time avoid it being onerous to add new objects/routes. I don’t envy @brad’s job in finding the best solutions to such things!
Neil
I like! Having these three options would give us the most flexibility to adapt to our individual working styles.
My issue with that would be that whenever I insert a new rack into an existing song (e.g. add a cheesy string layer to a piano), this would automatically de-activate the route to and from this plugin in all other states, which I’d have to manually correct. At the same time, the actual rack I insert is active across all states. Creates a discrepancy in behaviors, which is maybe not following the “principle of least surprise”, especially for beginning users.
I fully understand that for an expert user like you the previous behavior has its advantages; that’s why I suggested making that behavior adjustable via settings
Question:
With the old method when a new object was inserted, both the object and its routes were disabled in other states.
If I introduced a new option that could disable just the new routes in the other states (and not the objects) - would that cover it?
Brad
As long as that only applies when “enabled” state behavior is active for these routes, then I think yes!
Well it always will be for a new route, so I guess you’re referring to paste/duplicate operations?
Hrm… which makes me wonder whether the same option/logic should be used when turning on a route’s Enabled state behaviour.
Another question: with the latest changes is it too easy to destroy state information by turning off a state behaviour? (because if you turn it back on it’ll update that behaviour across all states)
Yes, that’s a very good point - we wouldn’t want to add that kind of inconsistency.
Neil
Not always - I’ve set “enabled” state behavior to “off” by default, using “Set As Default Behaviour”, so all routes come into being without state automation.
I can see that being a potential problem. So perhaps Cantabile could bring up an “Are you sure?” kind of prompt when you disable state behaviour on a parameter that varies across states.
Neil
Ah yes.
Or maybe make it undoable.
What about having this something that can be set up in the preferences? For instance, in MS Word you can set up in the preferences how text is pasted into documents. Sibelius has similar default methods that can be changed in the preferences.