State behaviour peculiarity

Cantabile
1

There’s a peculiarity in the implementation of state behaviour that I’ve been aware of for a while now, which I think is by design, but nevertheless, could cause people problems unless they have some insight into what Cantabile is doing under the covers.

Suppose I have a song with, say, 5 states. and I have a plugin with state behaviour disabled on its fader. And suppose the fader is fully down for all 5 states.

While I’m on state 5, say, I turn that fader up. Because state behaviour is disabled on it, if I then switch to other states, the fader remains up on all other states. That’s fine, and as expected.

However suppose after turning up the fader on state 5, before selecting any other states, I save the song and select a different song. When I return to the song again, Cantabile loads state 1, and lo and behold, the fader is fully down. Furthermore, if I select any other states, including state 5, they’re all fully down. My change to state 5 has disappeared, even though I saved the song. I would say this is not what people would expect.

Now I think I understand why this happens; each state has a stored fader value in the song file, and if state behaviour is disabled, the value is left untouched instead of the saved value being read, when selecting a state. And when you move away from the state, the current value is saved, thus overwriting the original. This is fine in general, but obviously not good in the above case; the state hasn’t had chance to overwrite the value into the file with the intended one.

It’s even more confusing with rack states, since their states are generally accessed in arbitrary order. So if you have a rack where a parameter has state behaviour disabled, but you haven’t stepped through all states to ensure it’s the same for all states, then the rack could behave and become modified differently depending on the order you select songs (and thus the order of rack states being selected). This feels wrong to me.

So basically, to understand state behaviour properly, you need to know how this implementation works under the covers, in terms of values being read / overwritten, and states being saved.

My question is - would it make sense to give some thought to rationalising this, so that when you change a value with state behaviour disabled, all other states get assigned that value there and then? Is there any reason why it couldn’t work that way?

Neil

1 Like
2

Hi @Neil_Durant,

Funny you should bring this up…

I spent most of today thinking about exactly this kind of issue, including the locked state stuff I mentioned in the other post and also a more predicable initial state for racks used across multiple songs. Also, state reset/revert all falls into this category.

I’ve come up with a couple of solutions, but none particularly elegant so I’ve not implemented anything yet.

My favourite idea so far is to introduce a concept of a “default” state. Unlike other states that only affect selected behaviours, the default state would set the entire state of the rack and serve as a predicable and editable base for other states to be overlaid.

Your idea of updating the non-state controlled behaviours is interesting too… Let me think about it some more. I’m open to other ideas here if any one else has thoughts…

Brad

3

I like that. I can imagine it also cutting down song/rack sizes too, because I bet a lot of people currently have lots of state behaviour enabled by default for stuff that isn’t changing, and thus having lots of duplicated data in the files.

Tricky area to get right though…

Neil

4

I always thought it did work that way, and you’ve uncovered an inconsistency.

I always thought it operated as follows.

  1. Enable behavior parameter for the first time imposes the value on all the states in a rack or a song part.
  2. Disable behavior parameter places all states into an ‘absolute’ mode and any state which is clicked on will adopt the new value. Unclicked states retain their previous enabled value.
5

Thinking more about this, I’m now imagining the faders with some kind of “ghost” knob showing where the default state’s value is, so you can see that the fader is different. I guess you couldn’t do the same for all state-dependent controls though - preset names for example wouldn’t work.

Neil

6

Just to clarify how this works under the covers:

  1. When you save a state - it captures every state controllable attribute (regardless of behaviour settings).
  2. When you load a state - it applies the attributes for the selected behaviours

Also, @Neil_Durant I just tried the steps you described in the original post and this doesn’t happen for me:

For any setting that’s not controlled by states it should always retain it’s value as saved. Are you sure you’re saving? Is there something else about your setup that might explain this?

Obviously there’s some confusion here and I need to clear it up, but still struggling to find a good solution.

Brad

7

I think that’s exactly what it’s doing. I’m talking about a setting with state behaviour disabled, where I’ve changed it on one state, but haven’t run through the other states to allow it to update (step 2 in your points above). Then if you leave the song, those states you hadn’t visited retain their original value in the saved file. Then if you return to the song, it loads those non-updated, saved values from the file, which will the percolate throughout the other states as you switch to them, thereby overwriting your original intentional change. It definitely happens on mine, and it’s not just an anomaly of the setup - it has always happened on all songs like that, which is why when I change a setting that has state behaviour disabled, I deliberately then step through all the other states in the song to allow my change to percolate through the other states, thus overwriting their saved values.

Neil

8

Hey @Neil_Durant, What am I missing here:

9

When you reload the song, it’s resuming from the state you left it, whereas I’m switching between songs in the set list, and it always resumes from the first state. I think that’s the difference (I’m away from a Cantabile box at the moment so can’t double check).

Neil