Non-parameter state in JUCE plugin

[rbuskov]

We have a sequencing plugin that only has a few parameters and lots of non-parameter state. We signal changes to non-parameter state to the host with updateHostDisplay(ChangeDetails().withNonParameterStateChanged(true)).

We have an issue with some users reporting that our plugin occasionally loses state when they save and reopen their DAW projects. Unfortunately, we have not been able to reproduce the issue but our best guess is that the host for some reason skips the call to getStateInformation when the project is saved, even though we have called updateHostDisplay.

I wonder if anyone has experience with similar issues, and how they may have solved the problem?

I have read about people adding a “dummy” parameter that they update whenever non-parameter state is changed, which seems like a crude solution - although I imagine it’s effective. Only problem is that there does not seem to be a reliable way to hide this dummy parameter in the host (i.e. make it non-automatable).

[leehu]

updateHostDisplay() is not guaranteed to be honoured by DAWs.
using a dummy parameter is the only way to solve this.

[rbuskov]

I have head several people say the same - but also people who seem to have success with using updateHostDisplay() - for example:

How can i set a certain parameter not Automatable?

Yeah… personally I don’t use the APVST for non-automatable paramater-like data at all. That is, I immediately stopped doing it once I figured that there are hosts which ignore the non-automatable flag (I’m looking at you, Reaper!). It’s ridiculous how quirky all of this is. While JUCE does a good job in general abstracting the individual plugin format quirks away and applying some specific workarounds for extra quirky hosts, I hope that at some point the industry will adopt a new and better thou…

UpdateHostDisplay withNonParameterStateChanged sometimes ignored by Reaper

Did you check that with the latest Reaper release? We were under the impression that this has been fixed from the Reaper side recently.

Text Parameter

The wrapper (plugin API abstraction) is an AudioProcessorListener. When a parameter is changed, the audioProcessorParameterChanged() callback is called and the wrapper communicates that to the host. Same for updateHostDisplay() which calls audioProcessorChanged() with the appropriate ChangeDetails flags. Try first if updateHostDisplay() works for you, it did for me, but I know there were reports that some hosts didn’t respond to updateHostDisplay(), so people added fake parameters to trigger …

Did you identify issues in any particular DAWs before deciding on the “dummy parameter” approach?

[rbuskov]

It turns out that updateHostDisplay(ChangeDetails().withNonParameterStateChanged(true)) does absolutely nothing in the VST2 and AU wrappers… now that explains a lot. As an added bonus, it also crashes Reason 12

After a full day of research and testing I’m inclined to agree with @leehu that the only viable solution is to create a dummy parameter.

I also found that, although most hosts actually do seem to respect the isAutomatable()property these days, a few of them also disregard non-automatable parameters completely. So trying to tuck the dummy parameter away by making it non-automatable renders the solution ineffective in some hosts.

It may be ugly, but an automatable dummy parameter seems to be the only solution that works consistently across all formats and hosts. Ugh.