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
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 
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 
He the eye also wanāt something 
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 !
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 
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