Issues when changing or adding racks in existing songs

[brad]

Hey @Torsten,

I had a look at this and found a bug in Update All States where the SavedBehaviour for the updated states wasn’t getting updated. I think this should resolve some of the frustration you’ve mentioned.

I’m still not sure what the best approach is when adding a new object to an existing object with states. Usually the approach I’ve taken is that the object should be configured such that when switching to a different state it’s as if it’s not there - ie: not to mess around with existing saved states.

For example, if you have a song with states and add a new route, when switching to another existing state that new route will be disabled.

So there’s already an existing mechanism to create a default non-affecting state for missing states - but it might not be optimally configured for some objects.

Brad

[Torsten]

@brad

So there’s already an existing mechanism to create a default non-affecting state for missing states - but it might not be optimally configured for some objects.

OK, interesting! This mechanism doesn’t seem to work for Racks, however - no state information whatsoever is created for new rack hosts, at least according to the song files I looked at. So if you update this mechanism to work for rack hosts as well, the problem of “undefined” state behavior should be solved?

Regarding the pre-setting of state behavior to be as “invisible” as possible in other states, I don’t 100% agree with the approach. I can understand your idea of new objects not affecting existing states if possible; I just haven’t found it very useful so far, TBH. When I insert a new object in an existing song, I am very aware that I am making a change, and I typically am not in the mindset “I am inserting a plugin / rack / route into a STATE”, but rather “I am inserting something into a SONG” - so I take care that I massage its behavior into something useful across the whole job - I find that is my job and not Cantabile’s.

So when, say, I have a song with multiple states, and I find that the piano could do with a string layer, I don’t want Cantabile to decide: “I’m going to de-activate that string layer in all states except the one you were in when you dropped the string layer in”, but rather make that decision myself explicitly. I don’t want to find myself scratching my head “why are the strings so silent in the 2nd chorus?” only to find that the route was de-activated by this mechanism…

So when inserting a new rack into a song, I would expect its default configuration (running mode “running”) to be the same for all states in the song - simple and non-surprising… Can’t think of an alternative default configuration that would be more useful for a rack.

There is only one scenario I have found where the existing mechanism was useful: when adding a new plugin to a multi-instrument rack with individual instruments being switched on/off depending on rack state. In that case, it saved me some state editing to have this new instrument only active for a specific state. But in that case, I was prepared to go and (1) make run/bypass mode state-dependent and (2) de-activate the plugin and use “Update All States” manually, in order to create that configuration; easy and predictable.

So I’d rather have new objects be inserted in a default state (and state behavior as defined per object type) in all song states, and having the responsibility myself to adapt them to song or rack states afterwards. Less potential for nasty surprises…

Just my 0.02 EUR, though - others may find the current behavior very intuitive.

Cheers,

Torsten

[brad]

@Torsten

Regarding the pre-setting of state behavior to be as “invisible” as possible in other states, I don’t 100% agree with the approach. I can understand your idea of new objects not affecting existing states if possible; I just haven’t found it very useful so far, TBH. When I insert a new object in an existing song, I am very aware that I am making a change, and I typically am not in the mindset “I am inserting a plugin / rack / route into a STATE”, but rather “I am inserting something into a SONG” - so I take care that I massage its behavior into something useful across the whole job - I find that is my job and not Cantabile’s.

@Torsten

Just my 0.02 EUR, though - others may find the current behavior very intuitive.

OK, that’s very interesting and something that I’ve wondered about. I’m starting to lean towards it’s being more confusing than helpful. Maybe letting go of this idea of keeping new objects invisible to old states is the root cause of all this confusion and I should just let it go and embrace the implications.

[cdv_gabriel]

@Torsten

There is only one scenario I have found where the existing mechanism was useful: when adding a new plugin to a multi-instrument rack with individual instruments being switched on/off depending on rack state. In that case, it saved me some state editing to have this new instrument only active for a specific state. But in that case, I was prepared to go and (1) make run/bypass mode state-dependent and (2) de-activate the plugin and use “Update All States” manually, in order to create that configuration; easy and predictable.

Just recently I prepared a huge rack with all sorts of amp sims for guitar (most of them demos or free sims), to try them out and compare them. I agree on both your remarks:

1. it has been useful that each added sim was not automatically active in all states
2. however, after inserting each amp I had to do lots of editing anyway, so the gain of not having to de-activate each amp by hand was not substantial

I was wondering: what about giving the user the choice of the desired behaviour when creating or inserting a new object in a multi-state environment? Something like:
“Do you want the [object] to be active in all states?”
YES/NO

Another possibility would be to have the desired behaviour controlled by an option (hidden in the option dialog).

just my 0.01 euros (ok they do not exists anymore…but who cares… )
Gabriel