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:
- To provide a sane method to reset a pre-loaded rack to a known state when switching songs.
- To provide a way to easily “Reset” or “Revert” a state through a menu command.
- 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:
- Apply State - The state controlled attributes are applied over the current settings, leaving non-state controlled settings as they were. (ie: the current functionality).
- 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:
- When loading states via bindings have two binding targets - one for apply, one for reload.
- 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.
- For song states - the first state (song part) is always Reload, all others are Apply.
- 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?
- Do the above settings provide enough control/flexibility?
- 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
@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).