Having managed to get my plugin to run in the Juce plugin host as a VST3 at last (still not quite worked out specifically how I messed that one up), I'm now running into a couple of issues with my functionality.
My plugin loads a configuration after startup, so the parameter definitions it initially gives to the host have dummy values. Once the real parameter names etc. are in place, I call updateHostDisplay() and in the VST2 version, the new names are correctly picked up by the host. In the VST3 version, however, this same technique doesn't seem to work, as I still see the dummy parameter names when I "Show All Parameters" from the plugin host.
I've tried to debug exactly what's going on and there's definitely some big differences in the code path taken by the VST2 and VST3 plugins from the updateHostDisplay() call. There doesn't seem to be any code that I can see that makes calls to getParameter after the initial setupParameters(), so I wonder whether this just isn't implemented yet?
There do seem to be some steps towards an implementation of this, in the restartComponent method in juce_VST3PluginFormat -
tresult PLUGIN_API restartComponent (Steinberg::int32 flags) override
{
if (owner != nullptr)
{
if (hasFlag (flags, Vst::kReloadComponent))
owner->reset();
if (hasFlag (flags, Vst::kIoChanged))
{
double sampleRate = owner->getSampleRate();
int numSamples = owner->getBlockSize();
if (sampleRate <= 8000.0)
sampleRate = 44100.0;
if (numSamples <= 0)
numSamples = 1024;
owner->prepareToPlay (owner->getSampleRate(), owner->getBlockSize());
}
if (hasFlag (flags, Vst::kLatencyChanged))
if (owner->processor != nullptr)
owner->setLatencySamples (jmax (0, (int) owner->processor->getLatencySamples()));
owner->updateHostDisplay();
return kResultTrue;
}
jassertfalse;
return kResultFalse;
}
The flags passed into that via the updateHostDisplay call are: (Vst::kLatencyChanged & Vst::kParamValuesChanged), but I think some of the other flags need supporting. Here's the full list:
kReloadComponent - The Component should be reloaded.
kIoChanged - Input and/or Output Bus configuration has changed.
kParamValuesChanged - Multiple parameter values have changed. (as result of a program change for example)
kLatencyChanged - Latency has changed (IAudioProcessor.getLatencySamples).
kParamTitlesChanged - Parameter titles or default values or flags have changed.
kMidiCCAssignmentChanged - MIDI Controller Assignments have changed [SDK 3.0.1].
kNoteExpressionChanged - Note Expression has changed (info, count...) [SDK 3.5.0].
kIoTitlesChanged - Input and/or Output bus titles have changed [SDK 3.5.0].
JUCE (and some other hosts) do not support the kParamValuesChanged callback coming from a plug-in and JUCE will not update the parameter names after it has initialised a plug-in.
I know there’s been some work recently on the VST3 implementation, which looks great btw, so I wondered if any thought had been put into supporting dynamic parameters?
At the moment it doesn’t look possible for me to have a VST3 version of my plugin (certainly not in its current form anyway).
We needed to do some other related modernisation work on the parameter code of the plug-in wrappers which is currently in code review. Once this is through code-review, published and dust settled, we’ll start investigating this a bit more. Sorry, we can’t give any more specific dates.
I too have just spent forever trying to create a dynamic parameter setup to no avail then found this thread. I really hope that this functionality becomes available soon! I also tried creating a dummy parameter and then populating the parameters properly at a later date with the idea of re-instantiating the plugin to refresh the parameter list but this did not work for me. Pretty gutted as it was a lot of wasted time .
Could you maybe point me in the right direction then with this because I can’t for the life of me get it to work even for vst2. So I’m trying to create components and then specify parameters afterwards. On instantiation the value tree is set up and no parameters are added from the processor thread. I then export xml from the ui thread with the parameter information once the ui objects have been created and call “updateHostDisplay()” from the audio processor. On re-instantiation the constructor of the audio processor should check to see if the xml is available and read the corresponding parameters providing the text names to “parameters.createAndAddParameter” . Is there a better method than this to instantiate parameters after ui components have been made?
The difference is that I’m not using the ValueTree method for setting up Parameters, as that didn’t work for me either. I’m creating them explicitly, using the AudioProcessorParameter class.
There is a bit of complexity around the fact that if I’m not working with dynamic parameters then I only create as many as needed for the configuration, but as standard I am able to load a new configuration and change the parameters that are configured.
Let me know if you want more details about this.
P.S. The code is used in two contexts, one of which isn’t a VST container, so you’ll want to imagine that __DLL_EFFECT__ is not set to see how this fits together in the VST context.
.