"Auto Update States" vs "Locked States"


#1

Hey All,

I’m doing a bit of design work around states and wondering about the following…

What if instead of each song/rack having the “Automatically Update States” option, each state had a locked option? This would let you permanently lock some states (unless you explicitly Update them) while still working on and auto-updating others. It would also prevent accidentally trashing a correctly configured state by accidentally leaving Auto Update States on.

I’m envisaging a little lock icon in the states panel showing which states are locked.

Thoughts?

Brad


Rack States as presets behavior
#2

A very good idea. I’d want to be able to lock songs as well.


#3

I almost always turn off the automatically update states option. I’ve messed things up too many times.

  • Paul

#4

Would be very useful for me also. Thanks Brad.


#5

Sounds potentially useful, particularly for rack states that you re-use in different songs. When creating a new rack state I often start with an existing one, modify it, and save it to a new state, so the padlock would give a bit of extra security against affecting the original.

I think it would also then be useful to have commands to set all states in a song/rack as locked/unlocked.


#6

But so useful when you know you’re in editing mode. It comes with risks, and we’ve all been there.
A lock would be a great comfort.
As long as we have a hotkey to turn the lock on/off.


#7

I’ve just finished implementing this. I think I like it - feels more controlled.

A couple of notes:

  1. Locking linked clones locks all the clones.
  2. You can manually Update State without unlocking if you like.
  3. If you switch to an unlocked state, make a change and then lock it, the change won’t be included in the locked state. Seems counter-intuitive, still considering…
  4. If you load an unlocked state, makes some changes and then insert a new state - the originally loaded state won’t get the changes - only the new state will capture the changes (this is as per before)
  5. I’m probably not going to create a default short cut key to lock/unlock but you’ll be able to set one up yourself if you like (Options | Hot Keys)
  6. You can multiple select or Ctrl+A select all to lock/unlock multiple states.
  7. If you load an old file with auto update states turned off, all states will be initialized to locked.


#8

Maybe 3 needs a “changes made, save?” kind of prompt?


#9

Maybe though not keen on a prompt. I think I’ll just make it update the state at the time it’s locked.


#10

I’m going to try out the latest experimental build again. These features would be really helpful.


#11

In my case I’d suggest the “Locked” function automatically active for new States or let the user decide what’s the default lock-state.


#12

Interesting idea. Logged it for consideration. Perhaps instead of an option it could just lock new states if the current state you’re saving from is locked.


#13

@brad
Did the hot key ever get in there for Lock State? I can’t seem to locate it.,
Just a note to say that Locked States is definitely a much more helpful option than Automatically Update was.
:ok_hand:


#14

Hi Ade,

Just checked, yep it’s there but not in the default hot key bindings. Go to Options -> Hot Keys -> Add, and then:

image

Brad


#15

@brad
Thanks for that! I followed your exact suggestion only to find that ctrl+alt +L does Lock only - won’t unlock :slight_smile:
Tried with Shift key too.


#16

Hi @Ade,

Hrm. Works fine here for lock and unlock. What build of Cantabile are you running? Does the menu command in the State menu work for lock and unlock?

Brad


#17

Running 3535 here, Brad
I wasn’t clear - single states are fine. It’s all on/off where unlock fails on my system.
The menu works.


#18

Hi Ade,

Ah! The lock all and unlock all commands are separate so at the moment, you’ll need to create two hot keys - one for lock and one for unlock.

eg:

image

I’ll add a command to toggle all for next build.

Brad


#19

Next build will let you do this:

image


#20

Still trying to wrap my head around the state lock thing. What types of things are locked? What does locked really mean? I have the states locked, I have also set them to “also reset this state when loading”. Each state has a lock icon and the circular arrow. I have also put a tick mark in every singe state behavior box that is related to the plugin’s parameter. Still, as I am playing, every plugin’s parameter change (via bindings) is remembered and reloaded in this now-altered state next time I play a song using same rack state. Nothing resets or reloads unless I close the entire program, remember NOT to save changes (otherwise I completely lose numerous hours of set up work), and restart the program. This is not ideal to do between each song we perform.
I don’t understand what the state behavior check boxes really do. It does not matter if a parameter’s state behavior check box is marked or unmarked, it still saves these parameter’s value in the rack state (most do anyways, so far I’ve only come across one parameter that did not save in the state changes until I checked the box for it). Even if I can figure out the purpose of these state behavior boxes I don’t think they are related to the states self updating or not.
All I need is that every time I click on a song (which is linked to a state within a linkable rack), I need it to load that in the state that I set up, and not the state that I left it in the last time it was played in the current gig. I can understand that if I clicked on the song that I was already on that it would not reload, although this would work great for me as a way to reset to the original values, that’s at least a behavior I would expect. I’m sure someone has a use for it, but I can not find the value in clicking on a new song (one not yet played in the set) and having it not sound how you set it up and instead sound like the end of a completely different that was played maybe a half hour earlier. I don’t need to understand the value in it, but I do need to understand how to completely avoid this behavior in every single instance. I never ever ever want it to do that. I don’t care if I have to change one master setting or multiple settings per every single state in every single rack in every single song. I just need a song to sound the way I programmed it to sound when I click on said song. If I were designing a program that was to be used to save the sounds I wanted to use on a per song basis, having these sounds load exactly as I set them when I click on the song would be priorities 1 through 100. Every single other function would be secondary, by a long shot. This is why I am still trying out the program and not yet asking for a refund. I simply cannot believe that this most elementary function and obvious greatest need is not obtainable. Why it is not by default befuddles me, but I have to believe it is doable or I have lost all faith in humanity!