Revert to the initial song does not work?

Hi fellows,

After playing a song/and editing the controllers, then switching back and forward to an other song,
does not reset that song to that initial state?
The revert function does not work for me?
What am I doing wrong?

Do you have set list pre-loading turned on? If so the song will be kept loaded and loading it again will reload the first state in the song (if you have states) and any state controlled behaviours should be reset.

How many states does your song have? If you have no states or only one state then the state of the song wont be reset.

Are you trying to revert a song or a rack? Are you sure the file hasn’t been automatically saved in the interim?

All of this falls under the general heading (and problem) or resetting transient controller changes - which is what this discussion is trying to solve.

Hi Brad,
yes pre-load is on.
But still it gets back to the altered version of the song, not the initial.
Maybe it is because in most of the songs i don’t use a state?

So possibly this is because of the new function, that pre-loaded songs will not be prompted?

So question: how can I reset to the initial saved version when switching?
I think it’s most important you can switch back to the initial state, because when you start playing a song and build up the settings during play, you can have a complete different soundscene.
So when you need to replay this song in your live set, you can’t start from the basic song?

1 Like

Hey Sven,

pre-loaded songs will actually stay as they are, if they don’t recognize an explicit “change”. This applies especially to rack states; if e.g. you have “song 1” with “rack 1” and “rack state A”: if this another song uses “rack 1” in “rack state A” as well, Cantabile will not think that it needs to re-load the rack - even if you have changed some parameters within that rack via controllers. That’s just the nature of pre-loading - unless an explicit change to rack state is recognized by Cantabile, a rack will not be re-initialized.

There have been discussions on rack re-initialization, but to my knowledge, these have not resulted in any implementation, so this is still the way things are.

To work around this, I use initialization bindings on song load for all the parameters that I manually change with controllers. Typical ones: rack volume (a final level plugin controlled by CC7 sent to the rack), tremolo depth (for ePiano sounds, controlled via ModWheel), hammond pedal (CC11), etc. My template song contains a number of these initialization bindings for my typically used racks; any unused ones, I delete when creating a new song.

This way, I am sure that all controller-based changes to racks get re-set; also, I get to initialize some parameter like leslie speed specifically for each song.

HTH - Cheers,

Torsten

3 Likes

@Torsten

Great info Torsten! I am going to re-work some things in light of this.

Many Thanks

Corky

2 Likes

Thx Torsten for the information.
I’m not sure, is this only applied to racks?
I think my problem is on song level.
Songs don’t revert to the initial saved version when switching back to them?

Well, after all, songs and racks are structurally pretty much the same…

When a song is pre-loaded in memory, the only things that get initialized when switching back to it are:

  • “Song Load” triggers/bindings
  • Settings attached to a song state - but only if the song is currently in a DIFFERENT state than the initial load state

The last one is important: when switching to a song, Cantabile checks if it is in a state different from the FIRST state. If not, it will simply stay as it is - the state will NOT be re-loaded. Same as with racks: if the state doesn’t change across songs, it will not be re-loaded. This is just Cantabile’s behavior: it is dictated by states - be it for racks or for songs; they’re just the same. If the state doesn’t need to change, Cantabile will NOT re-load it.

So if your song has just one state, Cantabile will look at it on re-loading and think “oh, the state hasn’t changed, so let’s keep everything as it was”. On the whole, this is healthy behavior; it avoids a lot of re-loading plugins, samples, etc… But it does make things complicated when you make changes to a state/song during a gig by using controllers.

I think there was a discussion some time ago on this forum about a “state reset” or “song reset” option; don’t quite recall what the consensus was, but nothing has found its way into a current version yet. The whole “state reset” feature is a bit complicated, since you don’t want ALL parameters to be reset on re-loading a song (you don’t want that 1 GB piano sample to be re-loaded…),.

So if you want to be sure that your controller changes get reverted, just insert some “Song Load” bindings in your songs for the parameters controlled manually and make sure they are where they should be at the start of a song.

For some songs, I even do this for every state change, e.g. to make sure the Leslie is on “fast” for the chorus. On other songs, I don’t do this, because I want changes I make in one part to carry over to the next (e.g. volume of the string layer).

Yes, it does take a bit more thinking and preparation, but as long as you don’t have large numbers of parameters that you change in a song, it’s workable.

Cheers,

Torsten

2 Likes

Ok understood,
So i need to add an initial state if i want this function.
Nice approach torsten!

It also happens when you DO NOT have a state for a song. Most of my songs don’t have one, so that function does not work.
Could I create a ‘reload song’ binding of function for that?

It’s worth noting that Brad is considering options for clarifying this area, and making provisions for songs to revert to a known “default” state, without the need for bindings etc.

Check out the thread: Seeking feedback: The “Default State”.

Neil

1 Like

Ok give me some hours to fully read that topic haha :slight_smile:
If there comes a default state, I hope it’s ‘hidden’, so that the second ticker view isn’t ruined with the word DEFAULT everywhere :smiley:
He the eye also wan’t something :wink:

BTW: testing the latest song grid version, and I love it, more info later.

Nope - there isn’t a function to “reload” a song. That will possibly come with the “Default State” option. For the moment, your only option is to use initialization bindings for the changed parameters.

Cheers,

Torsten

1 Like

I wonder if you could achieve a kind of song reload by having an extra “initialisation” song state, so that selecting the song causes a song state change? You could even set up bindings to select that setup state and then automatically select the next, “proper” state.

Neil

1 Like

Well, maybe a new per song setting, ‘initialise at load’ ?

According to Occam’s razor lets keep it simple as much as it possible ! :slight_smile:

Hmm, the problem with this is: what does “initialise” really mean?

The key idea behind pre-loaded setlists and shared racks is that a rack only gets loaded once and then re-used by all songs. Most of my songs only consist of linked racks, all re-used across a number of songs.

Now I load a song that uses a rack that has been used in a different rack before. How should the song know that this rack has been modified? Currently, the only way for Cantabile to recognize this is the rack state. If the rack state hasn’t changed, Cantabile will not re-load this rack - which is exactly what we want, because who wants to re-load the 1 GB piano for every song?

Now I change a parameter within the rack via a controller. Rack state stays the same.

How should I re-initialize the rack via an “initialisation” song state? The only way I can imagine would be for this “initialisation” state to have DIFFERENT rack states, so that racks get re-initialized on switching back to the song states. And that could get nasty with big sample-based racks…

So it’s probably not just about song states but also about rack states as well.

Maybe actually easier to use bindings for a small number of changed parameters…

Cheers

Torsten

Especially since you know precisely which parameters you’re modifying because you have bindings set up to modify them. So there shouldn’t be too much risk of missing any.

Neil

Initialise as the state it was loaded (and saved).
I think we’re talking about a different concept :slight_smile:

Nope - we’re talking pretty much the same thing - but the problem is what this means in consequence, and in the context of pre-loaded racks / songs.

The problem is that the only way to ensure that a song is fully initialized is to COMPLETELY RE-LOAD it and all its contained racks. And that’s exactly what we are trying to avoid with pre-loaded set-lists and racks - because it can take a shedload of time to re-load a rack. So, we don’t really want a full re-load, do we?

So the key question is: short of totally re-loading a song, which parameters should Cantabile initialize to their saved values when a pre-loaded song or rack comes up again? And how do we tell Cantabile which parameters we want it to initialize?

The easiest way to define this currently is to make it explicit with “Song Load” bindings - that’s what @Neil_Durant and I are currently doing. Tells Cantabile quite clearly which parameters to set to what value. And it has the advantage that it can work from song level, sending parameter initialization to racks via MIDI CCs (even without rack state changes), as well as from rack level, controlling rack parameters on a rack state change.

Another way would be to make sure that the relevant parameters to intialize are all state-controlled (state behavior checked), and then, on starting the song, change song and rack state to an “intialize” state and back to the states you need for the song. The disadvantage of this is that this means a complete state change for the song and all racks, which means that a lot more parameters and plugin settings are changed than just the ones you modified. This may mean some time delay because a number of plugins will then need to be switched to a new state and back; especially painful for sample-based instruments.

What @brad and a number of us were discussing in the thread @Neil_Durant mentioned is a mechanism to define more precisely what parameters specifically are part of an “initialization” set - and explicitly setting them in a separate “reset” state - both for racks and songs, I expect. Then you could truly have the song have the setting “reset on load” - which would set the parameters defined in the “reset” state to their saved values (for the song and all racks involved) - and leave the rest alone, so nothing would need to be re-loaded unnecessarily.

See why it is a bit more complicated?

Cheers,

Torsten

3 Likes