Hi,
I have been working on a feature but it became a big headache. I am simply trying to force host to call getStateInformation. I have a parameter called hiddenParamter that should not be seen on automation list. It should be invisible but host should keep track its value every time it changes. I tried to create it with “withAutomatable(false)”. It has disappeared from the automation but now when I try to change this value it doesn’t inform host and host doesn’t call getStateInformation. So whenever there is no another automatable parameter changes, host doesn’t call getStateInformation for my hiddenParameter. How can I hide this parameter in automatable parameters list and still notify host to call getStateInformation?
I have seen many posts but none of them helped.
I noticed that when the plugin window is closed, the host calls getStateInformation. My parameter is being saved when I open the plugin window and then close it but if I just insert my plugin and just change my hiddenParameter and then save the host session without closing the plugin window, host doesn’t call the getStateInformation.
A method that can trigger host to call getStateInformation would solve my all problems. I have tried to override a few methods to make host call getStateInformation but I could succeed.
You never mentioned what host application you are testing this with. But this is unfortunately the kind of thing where hosts might not have a universally working behavior. You may need to make your “bogus” parameter one that is visible for the host as an automatable parameter.
There is no way to force a call of getStateInformation. You can tell the host, that your plugin state is “dirty” and it cannot use the last result of getStateInformation() any longer. But when it calls it again, or if at all, is totally up to the host.
And even marking the state dirty seems not to be reliable, as you found out (that would have been the updateHostDisplay()).
Can you elaborate, why you want to force a getStateInformation() call?
Here is the story. I want to allow users to be able to choose a color for their plugin instance.
For example my plugin has 10 different background images. For each plugin instance user should be able to pick the colour he likes. Let’s say user created a track and inserted 10 instance of my plugin. User should be able to pick a different color for each plugin instance. At the same time i have a preset manager system. For each preset, user can choose another color and save it within preset. This is also should be memorized. I am already parsing the xml tree of the juce and adding additional parameters to it. All default juce parameters starts with “PARAM” id. I use a different tree name called “SKIN” and all hosts ignores this. It works fine. I am storing the color name and pulling it back from valuetreestate when I need it.
There is only one issue. Since I am keeping this SKIN data in the valuetreestate of the plugin, I am only able to modify the tree.
Let’s say user opened the DAW and inserted my plugin. Default colour is grey. Then user clicked on a popup menu and picked another color. And I replaced the value of the SKIN from grey to red. But DAW still doesn’t know if that SKIN parameter has changed. If I trigger the daw to pull (call getStateInformation) current state of the tree, daw will also know the new value of that parameter. Without changing any parameter, if user only changes the SKIN and then try to close the daw by saving the session, my modified tree won’t be sent to daw. Daw will still keep the old one that has SKIN:grey. Whenever I open the session it will forget the choice.
If user inserts the plugin and changes the color and then closes the plugin window which will trigger daw to call getStateInformation, the tree will be updated and if user saves the session and comes back, it will display red background because it got triggered and call the getStateInformation.
So in conclusion, there are some certain situations that somehow trigger daws to call getStateInformation. The example that i mentioned above works the same in all DAWs that i tested.
If updateHostDisplay(or anything else) worked, It would solve all problems. I tried to dig the attachment class to see if there is a way to trigger the daw but it looks too deep, I don’t want to use a different bracnh of juce just to get this feature and I don’t know if I am going to be able to do it.
As @daniel already stated there is no way to tell the host to call getStateInformation. We ended up using a dummy audio parameter which we change whenever our plugin‘s state has changed. Since updateHostDisplay isn‘t guaranteed to work, this way we make sure.
