I have an issue where plugin state is not saved neither restored when closing and reopening the plugin ui. So upon initial plugin opening the host calls getStateInformation() and setStateInformation() functions as expected. After closing the plugin UI getStateInformation() is not always called by the DAW host -> more interestingly, when testing on Reaper the function always gets called but on Ableton Live it never gets called by the host. On the other side setStateInformation() is never called upon plugin re-opening neither in Reaper or in Live.
Does anyone have similar issues?
I am using JUCE 4.3.1 and the same issue is reproduced on MacOS as well as on Windows.
You will have to ensure in some manner that your GUI is up to date from the AudioProcessor state. The usual way is to have the editor inherit Timer and then in the timerCallback check if the GUI components have different values compared to the AudioProcessor states and if they do, then update the components. (Make sure the components don’t then cause a state setting feedback loop.)
Thanks for feedback.
The main issue is that processor state itself is not updated by the host since setStateInformation() function is never called if I close and then re-open the plugin again. So it get’s called only upon initial plugin opening. This part of the code that updates the UI from the processor state is working well (since it works for initial plugin opening).
That’s not what setStateInformation is used for. It is called when a session is restored.
Live updates are communicated from the host calling AudioProcessorParameter::setValue(), and either your attachments or AudioParameter::Listener will react to that.
I wouldn’t expect the host the call call getStateInformation or setStateInformation when the plugin GUI is opened or closed, since that should have nothing to do with the main operation of the plugin.
However, if you are saying your actual audio processing code does not get properly updated, then it’s a different issue. The host should be calling getStateInformation and setStateInformation when saving and loading the host project, and possibly when doing undo in the host.
The host may also be creating the GUI and recalling the state in an unexpected order like first creating the GUI and then setting the state information. You can’t trust the AudioProcessor has the correct state when the AudioProcessorEditor is created. Also take into account host automation, users will want the plugin parameter components to reflect that…
Note that the poster is using JUCE 4.3.1, so he may have limited options as far as the parameter handling goes…
Yes, thanks for pointing it out, I read that. But I think the AudioProcessorValueTreeState was already around? Need to double check…
But the flow is the same:
- Slider is calling parameter->setValueNotifyingHost(…)
- this is sent to the host, the host will check, if that suits the automation setting (if applicable)
- host sends the (possibly corrected) value back calling parameter->setValue(…).
But @Xenakios is totally right, it doesn’t matter at all, if the GUI is open or closed.
Thank you all for clarifications. Ok, then I misunderstood the usage of getStateInformation and setStateInformation functions which I thought will be called each time when re-opening the UI.