setStateInformation / AudioProcessor initialization order


I know that get/set stateInformation funcions are called by the hosts whenever they want to, but my question is: is there a way to make the plugin initialization happen ONLY when the setStateInformation call is already done? I am storing some properties in AudioProcessorValueTreeState that I am using as options for the initialization of the plugin. Is this bad practice? Is there any way to ensure that the state is loaded before instantiating the plugin with the user’s latest updated options?


You can always keep your own flag, initialised to false and set to true, as soon as setStateInformation was called. But in practice it won’t work, since when you select the plugin the first time into a track, the host doesn’t know what to set the state to. So there has to be a getStateInformation call beforehand.

To set default values in the ValueTree, either you set them explicitly in the constructor creating the whole tree, or you set them implicitly, when you access the value with var getProperty (property, defaultValue).



Thanks for the reply. I am already using a default value for the value tree, so that’s not the problem. The real problem I am having is that the host is calling the setStateInformation after I have already initialised the plugin using the ValueTree properties of the state. I was considering using a flag to check if the setStateInformation has been called, but even then if it gives me false, I am not sure who should trigger the reinitialization of the plugin after the setStateInformation has been called. Calling the reinitialisation directly from the setStateInformation seems wrong because the method can be called more than once, depending on the host. Is it possible that there is some neater way to synchronise the two things?


It could be a legit reason for the host, so you have to reflect the changes from the setStateInformation. E.g. the user clicked “Revert session to saved” or whatever it is called in that host.
A neat way is to register a ValueTree::Listener and update your values from there (if you are talking about non-AudioProcessorParameters). That way you also get undo/redo behaviour already sorted (if you consistently use the UndoManager)…