Seeking feedback: The "Default State"

Cantabile
1

Hey All,

As hinted to here, I’m considering adding to Performer a concept of a “default state”.

The idea is that it’s a special state that captures and restores the entire state of the song/rack - regardless of the state behaviour settings. ie: Editing the default state will edit the non-behaviour controlled settings for all other states.

It’ll serve a few purposes:

  1. To provide a sane method to reset a pre-loaded rack to a known state when switching songs.
  2. To provide a way to easily “Reset” or “Revert” a state through a menu command.
  3. To provide controllable way over when the default state is updated.

To clarify point 3… I’m making some changes to the way song and rack saving works such that racks will be optionally able to “always save” when unloaded (see here) but it means the “saved rack” doesn’t provide a suitable base for resetting since if it’s auto saved after transient/binding induced changes then it’s not predictable where you’ll come back to.

By having a lockable/editable default state that captures everything you can explicitly decide when and how to update it - regardless of when the rack file is saved.

That’s all well and good and I still need to design the editing side things but it raises the bigger issue that there are now two ways to load a state:

  1. Apply State - The state controlled attributes are applied over the current settings, leaving non-state controlled settings as they were. (ie: the current functionality).
  2. Reload State - the default state and the selected state are merged and everything reloaded so that non-state controlled attributes are reset to the default state.

There are use cases for both. When switching songs, “Reloading” referenced racks provides a neat way to reset previously used pre-loaded racks to a known state. When switching between song parts you probably want to “Apply”, but switching states on a rack mid song you might want “Reload”. It depends.

So I like this idea of default state - it makes the state management with pre-loading turned on a lot more predicable. However I don’t want to introduce a bunch of settings to control when merging does and doesn’t take place. I’m trying to simplify things not make it worse - so any settings here need to be simple and obvious.

My current thoughts are this:

  1. When loading states via bindings have two binding targets - one for apply, one for reload.
  2. A simple on/off button on the rack slot in the parent song next to the state selector that controls reload vs apply. Generally you’d turn this on for the first song part (so that referenced rack states are “reloaded” when the song is loaded) and off for other parts so your transient in song changes (eg: expression pedal) don’t get reset.
  3. For song states - the first state (song part) is always Reload, all others are Apply.

Questions:

  1. How do you feel about the idea of a default state in general? ie: Is it a good idea, does it clarify things or just make things worse?
  2. Do the above settings provide enough control/flexibility?
  3. Terminology - I think some of this could be clarified with the correct terminology but I’m drawing a blank. Some options:
    • Apply State vs Reload State (current favourite)
    • Load State vs Reset State
    • Partial Load vs Full Load
    • Suggestions?

@torsten - I’d be particularly interested in how you feel about all this. I know you’re quite happy to manage this stuff through bindings but how would you see this fitting into your current setup.

To be clear I’m not planning on introducing anything that will break existing setups (at least not intentionally).

1 Like
2

My little thoughts to this:

I like the arising possibility to apply a state-behaviour from one to all the others and I think it’ll clear up some (mysterious) things. I suppose, that if I make a change in state 4 on a parameter, that is not marked to be controlled/saved it’ll be applied to all the states in this song, right? This answers question one.
2nd question: for me, Yes.
3rd: for me “Update” vs “Reset” would be the right terminology. Because “update” indicates, that only the settings, that are set in this state will be updated, any changes done til there will be left untouched - if I understand the concept correctly.

My main concern: a default state MUST NOT be included to next/previous state list

3

No - that’s kind of the point of all this. If you changed that parameter via a binding during performance for example you probably wouldn’t want that change applied to all other states. If you changed that parameter in the default state however then when merge+load other state then yes you’d get the new setting. This is getting into the editing side of it however which I haven’t completely designed yet and still need to think about.

Agreed - it wouldn’t be.

4

Hi!
Well… what If any state could be marked as the default state (not a special dedicated one)?

Kind regards, Alexander

5

Yep I considered that too. I even considered being able to mark multiple states as “base states” and any state after it in the list would use that base state. I also considered letting user select another state to serve as the base state for this state.

But… it just seems so messy and probably only 1% would find it useful. One default state is easier to manage and also lets me break it out in the UI for more clarity more easily.

To be clear: much of this me just thinking out loud… I’m still trying to figure out the best approach and nothing has been decided yet.

1 Like
6

Hi @brad

sorry for the late reply - was a bit busy, and then I had to wrap my head around your idea to understand what it could mean to me in live operation.

Generally, I find the idea of having an explicit “initialization” state pretty useful, especially, when a number of parameters are “non-state-controlled”. This makes it very clear how a rack or song is initialized on loading, which currently is a bit of guesswork. So all for that!

Also, I like the idea of the first song state being “Reload” - makes sure that a pre-loaded song always feels the same on entering (with the exception of non-song-controlled racks like my master rack), even when you play it twice in a set. Makes sure that changes during the first playing don’t carry through to the second playing. Good solution!

Regarding my specific solution of managing things via bindings: currently, I do two things with bindings

  1. Set volumes and effects levels for all song racks back to their default levels via MIDI CCs to rack MIDI in, in order to nullify any changes during the previous songs.
  2. Set some rack parameters are explicitly set to song-specific levels, e.g. ePiano tremolo depth, leslie speed, string layer initial level.

I guess the first category could be completely solved by a Reload of all racks on song start. The second category, I would still need to use, since the default state for a song won’t send MIDI CCs to my racks.

But overall, this would definitely help me clean up my bindings page quite a bit!

There is one downside to the “default state” concept: currently, when I work on a certain state, and I change one of the parameters NOT controlled by states, this change is automatically saved with the song when I save it. With the default state, I assume that I will first have to navigate from the current state I am working on to the default state, make the change and then go back to the state I am currently working on? But for that, I need to be pretty sure of the state behavior of all of my parameters. Or will the behavior be that all changes not influenced by state behavior will automatically be reflected back to the default state and saved with it? @brad: I’m interested in what your thinking is on the editing side…

Cheers,

Torsten

7

I do think it could be useful to have a “save as default” option to customize what the default would actually be for a given user. But I can see where it might be needlessly complicated.

8

Good to hear. I’m still undecided on this but it’s the best idea I’ve got so far.

What I was thinking here was a new command “Update Default State”. This would snap shot all the non-state controlled settings into the default state.

Possibly but I think an explicit command is better.

I think the full set of UI changes will be:

  1. a fixed “default” state at the top of the state list which will be editable/lockable like all other states, but excluded from state navigation (first/next/prev/etc…).
  2. the default state wouldn’t have name/program number associated with it.
  3. a new command Update Default State
  4. a new command to Reload State which will load the merged state.
  5. a new toggle setting on the rack slot in the parent song to control whether to reload or apply state changes when loading the selected state. (this setting will be state controllable)
  6. two new context menu commands on selected behaviours (in the behaviours panel): Update and Update Default which will update just those settings in the current or default state (respectively)

Also, I’ve already made some changes to the main menu to consolidate all the state related commands:

Pasted image747×485 19.3 KB

Brad

1 Like
9

I like it. I had been harping about locking songs as well but I guess if you lock all your states you’ve locked the song by default…

1 Like
10

Not really because states only control settings on objects - not whether the object is there in the first place. eg: deleting a plugin isn’t covered by states, it’ll disappear from all states.

However, you can effectively lock a song via File → Song Options → Mark as Modified → Never.

1 Like
11

Having spent the last day or two digesting this, I think it definitely sounds like it’ll make things more controllable and predictable, and easier to understand what’s happening. The ability to have an explicit default state upon which others are based, gives a certain solid feel that I think we’ve been lacking.

Like @Torsten, I use bindings for setting/resetting things I control dynamically during performance, although in my case I tend to encapsulate these into racks, and use rack states to determine whether things should be reset or whatever. I think the default state stuff described here should simplify this, with the on/off button in the rack slot to determine whether racks are reloaded/reapplied.

I have a question about this though. If a rack has the same selected rack state for two song states, I’m unclear what exactly will happen when switching between song states, with regard to the reload/reapply button. I guess reload will mean the rack state is definitely reloaded, forcing any transient change to be reset. But with reapply, will anything happen to the rack, if for example bindings have changed a parameter that is rack-state dependent? I’m just wondering whether this on/off button should have three states - Reload, Apply (re-applies saved state-dependent settings, overwriting any parameters changed by bindings), and None (leaves the rack as it is, including any parameters modified by bindings). I guess if the rack’s selected state does change between two song states, that “None” option wouldn’t be selectable, as it makes no sense - the new state has to be applied somehow.

Other than the above question, the only slight concern I have is the separation between editing non-state-controlled parameters in a state, and the default state. If I modify a non-state-controlled parameter in a state, and don’t do “Update Default State” or whatever, what would happen to that modified parameter? Would it simply be forgotten if I change to a different state? Or would that parameter in that state be in a kind of limbo, where it’s not state-controlled, but it’s also no longer controlled by the default state? As @Torsten alluded to, it sort of feels like modification of non-state-controlled parameters should directly control the default state, although I can see the danger of this too - it won’t necessarily be obvious when you tweak something whether it’s changing just this state or all states.

Perhaps non-state-controlled parameters that no longer match the default state should appear in a different colour or something, so you can see you’ve made “unsaved” changes, and these will be lost if you change state, unless you do “Update Default State”. That way, it’ll be harder to forget to save those changes, but will also require an explicit command to modify the all-important default state.

Maybe state-controlled controls should be a different colour to non-state-controlled controls anyway, so you can clearly see whether you’re about to change just this state or all states, without needing to consult the state behaviours pane.

There definitely feels like some scope for conveying what’s going on with parameters via colour here - it just needs some careful thought to reach a good design that helps understanding, without looking cluttered or confusing. Perhaps it could even be extended to show which parameters have been modified by bindings rather than directly.

Regarding song states, and in particular the way the first song state would always be reloaded, whereas subsequent ones would be applied, might it then make sense for the first song state to actually BE the default state? Just for song states - I think for rack states you really need a separate state.

The idea you mentioned about having multiple default song states, where subsequent song states are based on the previous marked default is interesting. But I think it’s probably overkill in general.

One suggestion - when creating a new state, it might be useful to be able to choose whether it’s based on the current state (as I think it current behaviour), or whether the new state is a copy of the default state.

Regarding your questions:

  1. I like the default state idea - it does seem like a good idea. I think it might appear a little more complex, but only because it’s more explicit. Currently, the complexity is hidden, so you can’t actually see what’s happening, or why your racks aren’t doing what you expected, which is definitely worse.
  2. I think it provides enough control/flexibility, although I think my question about control of what happens when two song states have a rack with the same selected rack state might need consideration
  3. Terminology is difficult for this! Apply/Reload aren’t bad, but it’s still not immediately obvious what they mean (but then the same applies to the other options you mentioned). It sort of feels like you have a “Base” state and “Overlay” states, which are applied onto the Base, so perhaps using the verb “Overlay” might help clarify things. A little like layers in Photoshop or something. Actually, I think I prefer “Base” to “Default”, as it implies something upon which a state is built - an underlying baseline. Whereas “Default” sort of sounds like the state you get if you haven’t selected anything else.

Neil