New Feature - State Reset

Hey All,

As hinted to yesterday (bonus points to @Torsten for noticing :slight_smile: ) I think I’ve finally figured out an elegant solution for State Reset in Performer.

Check out the guide and let me know what you think.

Hoping to ship this next week as part of a bigger set of experimental changes.

Reference: previous discussions on similar topics: here and here.

Brad

This looks really great Brad! I am glad transient settings are being addressed. I also peeked at the many other changes you have been working on and I am really getting excited to try them out.

Many Thanks

Corky

Thx for this function, looks promissing.
Is there a basic state reset possible when you do NOT have any state configured?
Most of my songs have no state and use the song settings?
States are nt needed here and only complicated the programs.
So it would be good to have a reset possible when switching back to that program (song).

Ow pardon me :slight_smile:
Brad already thought about that !!! Whohooooo

RESETTING SONGS
When Cantabile loads a song, it automatically performs a reset load on the first song part. You can manually reset a song using the previously described State -> Reset and Revert State command.

Thanks guys.

Yep state reset can work even when no state - in which case it applies the captured reset settings and nothing else. I’m not sure I’ve covered the case you described however - racks with out states, I’ll double check that you can make the song reset the rack in that case too.

Brad

1 Like

Hey people,

looks like a great idea. But could you give some examples where this function could be useful what can’t be covered with states already? I’d be happy to hear your ideas!

The primary use case for this is when you have a rack used in multiple songs and a setting in that rack is being adjusted by a binding (say a slider, expression pedal etc…) and you want that setting to be reset when you switch songs, but not when you switch states within the song.

Suppose you have expression pedal bound to a setting in a rack. When you switch states within the song you want the expression pedal bound setting to be unaffected by the state changes - so you shouldn’t include it in the state’s behaviours.

But since the behaviour of the bound setting isn’t turned on it’s not affected by states and if you save the rack it’ll save the current value - which could be anywhere depending on where you last left the expression pedal.

Now you want to use the same rack in another song and you want to make sure the rack loads in a well known state (eg: as if the expression pedal is fully released). You need a way to “reset” the state of the bound setting.

So for this bound setting you’d set it to where you want it reset to, right click on it’s behaviour and choose “Capture Reset Settings”. Cantabile will capture that setting and use it to reset the rack.

You can then instruct particular songs to reset the rack by turning on the reset state setting in the parent song for the first song state. The same mechanism also works on song settings and songs without racks - you can capture settings for any state behaviour and regardless of how the song is saved, it’ll be reset to those explicit settings next time it’s loaded.

The biggest limitation with what I’ve implemented so far is that there’s only one set of reset settings - so all songs have to reset to the same settings. I might change this, but not sure it’s really required.

That looks really good. I remember the original discussion threads about this, and it’s a complex problem to solve cleanly, but I think the proposed approach solves it without adding too much complexity.

My only reservation would be that “Revert” and “Reset” might be confusing terms to users. I can’t think of anything clearer without making it wordy, though, for example “Revert to state” and “Reset transient changes”.

Three additional things I’d be interested in:

  1. Having a binding target for resetting songs or racks to their saved reset state.
  2. Having Cantabile detect when things are modified externally (“transient settings”), but which are configured to be driven by state, which has the potential for doing something unexpected by the user. Some kind of visual indication, or perhaps part of Verify Setlist maybe?
  3. How about if items in the state behaviours panel change background colour if they no longer match their preset or reset state? This could be really useful.

Neil

Well, I don’t use states at all - too cumbersome - as I pretty much only use three instrument plugs and very few VST efx, I pretty mostly only run songs - but I can see the benfits to those who do use states. Another example of Brad moving the C3 prject foward all the time. Kudos!

Looks pretty good; one thing that comes to mind when reading through this for the third time now:

  • Let’s assume I have just created a song with a large number of linked racks, all of which I want to reset at the beginning of the song.
  • Now as I understand @brad’s guide, I need to tick the box “Reset State” on each of these racks for the first state of my song
  • next I need to UN-TICK this box for the second state - again for all individual racks - so that my transient changes have continuity across song states

For a large number of racks, this sounds a bit cumbersome - so what about a Song->OnLoad binding with “reset all racks” as a target? This way, I wouldn’t need to specify “Reset State” for all my racks for the first state in a song - which is probably the most-used scenario for state reset - but simply create one binding to do the “global reset”. And specialists like @Neil_Durant, who want persistence of some parameters across song transitions, could still customize at an individual level which racks to reset and just NOT use a “reset all racks” binding.

@brad: how about that?

Cheers,

Torsten

Good point @Torsten. An alternative would be that the “Reset State” tick box for rack states defaults to set in the first song state, and unset for subsequent states.

A small concern I have is that the “Reset State” tick box is rather hidden - you have to step through each state and open up the rack state drop-down for each rack, to see what’s happening. How about moving the tick box up onto the rack’s row itself, so it’s more visible?

Neil

Thanks everyone for the comments…

I agree and I’m still thinking about the terms. Open to suggestions, but it’s difficult to describe in a few words.

Good idea

I like both these ideas too but will probably collect some more feedback from usage before deciding where to take it next.

Good point - let me think about this. Perhaps even better than a binding, just a song option that says to reset all racks on song load. Let me think about that.

If you look closely at the screen shots in the guide you’ll see that when Reset State is selected, a small reset icon is displayed to the right of the state name in the rack slot so you tell just by looking at the rack slot if reset is enabled for it.

The main thing I’m still wondering about if one reset state is enough. @Neil_Durant and @Torsten do you have cases where a rack needs to be reset to different values in different songs? I’m thinking of two possibilities here, both of which would be reasonably easy to add, but I’m not sure either is a good idea:

  1. Every state has it’s own reset state (rather than one shared reset state)
  2. There’s still the one shared reset state, but add the ability for a state to opt-out of the shared reset state and have it’s own reset state.

Brad

Aha yes, I see that now. Very tidy.

I was actually going to ask something related - whether the captured state is part of song state data, allowing different resets to happen in different parts of a song (a well as different songs).

I think for my own usage, a single reset state per rack will cover the vast majority of my own needs (if not all). My main use for this feature is to reset parameters controlled by MIDI controllers to a known good default, and the reset state will almost always simply reset to a standard, known, nominal value. All my racks have a separate fader before the output, devoted to expression pedal volume changes, and reset would invariably set these to 0dB / unity gain. But this is because I tend to use expression pedal volume for fade ins/outs, and not for manually adjusting the right level for a given sound (which I have separately pre-programmed).

Part of me feels that it might be best to keep this feature intended for “resetting to a known rack default”, rather than encouraging it to be used as a tool to achieve song-specific creative choices. On the other hand, if rack reset state could itself have optional song state dependent behaviour, it would add a lot of power. Example use cases would be where a song part sometimes needs a transient volume fader to start from zero for a fade-in, and sometimes it needs to be set to unity for normaly playing, or for a fade-out. But I think if it were given that capability, racks should have their “reset state” state behaviour un-checked by default when added to a song, so it provides the basic rack-driven reset by default.

I’m slightly erring on the side of giving rack reset state a song state behaviour checkbox, the more I think about it.

But I feel that your second possible option might taking the complexity a little too far, and it could be hard to follow what’s going on (let’s face it, even just states are an advanced feature for many). The second could could always be achieved by giving rack reset state its own state behaviour, by just using the default reset state on any song states that wouldn’t want to “opt out” of the shared rack state.

Another separate question I had was what would happen if, for example, a fader is reset to 0dB by the reset mechanism on song load, but the song also has a song load binding to set it to some other value. Will we potentially get a brief glitch?

Neil

Thanks @Neil_Durant - some interesting thoughts there, but nothing that changes what I’ve already implemented so I think I’ll release what I’ve already done and refine it once everyone’s had a chance to play with it.

Good question, possibly I guess, but no different to how it is now if you have a state that sets a value and then a binding that modifies it. I’ve not heard of any issues in this area.

1 Like

I’ve been thinking about this some more and for the moment, I’m going to leave things as they are - at least until I gather some more feedback.

Also, re this:

You don’t need to untick for the second state. That “reset state” option is per-state and off by default - so you just need to turn in on (for each rack) in the first song state and you can leave the other song states alone.

Still… I might just add a command to turn on reset state on/off for all racks to save having to going through each one.

Hey Guys,

I’ve made some changes to try and clarify and simplify things a little. See the updated guide but specifically:

  1. The “Capture Reset Settings” command has been renamed to “Capture Defaults for Reset”
  2. The option to specify that a state always performs a full reset has been moved from the context menu to the Edit State dialog and renamed to “Also Reset when loading this state”
  3. The separate revert and reset commands have been combined to a single command “Reset” which performs a reset+reload on current song/rack.
  4. The checkbox in the state selector popup for a rack slot has been renamed from “Reset State” to “Also Reset the Rack”
  5. There’s a new command “Tools -> Reset All” which resets the song, all referenced racks, sends all sounds off MIDI commands and stops all media players, metronome etc…
  6. Bindings targets for Rack/Song Reset and Engine/Reset All

For the most part, it’s functionally the same as before - just tweaking the terminology/UI to clean things up a bit.

Oh, and @So_Godly I fixed it so that reset now works on racks that don’t have any saved states.

Brad

1 Like

Love you man :kiss:
It will all come clear when using it, but I think this is a great feature.

Maybe some little feature request, Hahaaaa, add a backup now, or version history, with multiple song versions saved, in case I mess things up again lol.
Anyway i will make a backup of my songs before starting the update.

Thx !

I just found out that Win10 has an integrated backup function. I didn’t check that yet but it seems promising!

I just have all my Cantabile files in Dropbox, which has automatic versioning built in, allowing me to revert to any saved version of any file :slight_smile:

1 Like

Oh, really? Didn’t know that!