VST3 parameter name changes don't work

Audio Plugins
20

Since this patch has been added I tried to update my plugins to report changed parameter names to the host for vst3. While this does work, there is a big issue with UpdateHostDisplay() and void audioProcessorChanged () that gets called by it in the wrapper. The problem is this line:

componentHandler->restartComponent (Vst::kLatencyChanged | Vst::kParamValuesChanged | Vst::kParamTitlesChanged);|

It means every time I change a parameter name, the host thinks latency changes and latency changes lead to audio “glitches” in many host. The line above is just too broad. It really should not sem kLatencyChanged unless the latency has changed and the same goes for the two other flags. In general the UpdateHostDisplay() is just a bad mechanism as it is too broad. IMHO it should be split into multiple calls or have a flag-mask to specify what parts of the host display should be updated. It’s a similar story in AU and I think it comes from the old VST where there was just one call. The newer plugin standards would allow for more fine control here and it would be nice if JUCE could reflect that. At the very least the VST3 wrapper should avoid sending latencyChanged if it hasn’t changed. I’ll prep a PR now.

EDIT: restartComponent() is probably a bad idea in general. Surely there must be a way in VST3 to change a parameter name without needing to tell the host to restart the whole plugin. From the VST3 docs:

/** Instructs host to restart the component. This should be called in the UI-Thread context!
**\param** flags is a combination of RestartFlags */
**virtual** tresult PLUGIN_API restartComponent (int32 flags) = 0;

There’s an IMPORTANT NOTE in the JUCE docs about audioProcessorChanged(…)

/** Called to indicate that something else in the plugin has changed, like its
    program, number of parameters, etc.

    IMPORTANT NOTE: This will be called synchronously, and many audio processors will
    call it during their audio callback. This means that not only has your handler code
    got to be completely thread-safe, but it's also got to be VERY fast, and avoid
    blocking. If you need to handle this event on your message thread, use this callback
    to trigger an AsyncUpdater or ChangeBroadcaster which you can respond to later on the
    message thread.
*/
virtual void audioProcessorChanged (AudioProcessor* processor) = 0;

Currently for VST3, UpdateHostDisplay() calls audioProcessorChanged() in AudioProcessor which calls audioProcessorChanged() in the VST3 wrapper which then calls restartComponent(). These are all direct calls. This means currently it’s a bad idea to call UpdateHostDisplay() for VST3 while audio is running - which might be always.

I also looked into crafting a PR to fix this, but it would involve changes in AudioProcessor… so I won’t even try to get it right. For now, I’ll just disable reporting parameter changes for VST3 in my plugins.

2 Likes