I am unsure whether this is a bug, but this surprised me so I figure it is worth posting.
I am working on a plugin host, in which currently audio is not always being processed and I encountered the following issue: VST3 parameter saves are (for some plugins) broken without audio processing.
Details
Without an audio processing call before calling setStateInformation, some VST3 plugins (for instance Pro-Q 3) save with default parameter values. Calling processBlock() once before setStateInformation fixes this.
I traced this back to inputParameterChanges->set (cachedParamValues.getParamID (index), value, 0); in juce_VST3PluginFormatImpl.h.
Reproduction
For a quick reproduction, commenting out audio processing in the AudioPluginHost JUCE demo also demonstrates this issue. Is this a bug or are my expectation of the behavior wrong here?
I was in the middle of trying to figure this out! Looking forward to hearing why this happens.
It not only happens on state load but also if you set the parameter values directly before calling processBlock, the first samples are not processed using those new settings.
I am working on a command-line host and could offer a script/repo for easy reproduction if needed.
1 Like
I found the answer for my case… and it was actually a misuse of APVTS in the plugin. As often happens… it was in the docs:
When the plugin using an APVTS provides its state to the host, it has to flush the parameter values to the state first, using the copyState function.
I don’t think that is the issue on my end, as I am testing with plugins that I have not developed that seem to be working well in other hosts. I will create a minimum reproducable example and post it here
If it’s the APVTS, you’ll need to run the message & timer thread for long enough for the APVTS timer callback to kick in and flush the parameter updates.
Since you mention FabFilter, though, I don’t think it’s the same issue since I don’t believe they use APVTS.
