VST3 plugins in Plugin Host do not respond to editor changes


I’m using Juce 4.2.1 (latest version) and the VST 3.6.5 SDK (latest version), though I had the same problems with Juce 4.1. I’m building the “Plugin Host” example project included in Juce 4.2.1 using Visual Studio 2015 on Windows.

For testing, I’m using three VST3 virtual instruments: u-he Podolski, a free VST3 plugin by an established pro plugin developer; and Arturia’s Oberheim SEM V and Wurlitzer V demos.

In every case, with these VST3 plugins (and every other one I’ve tried), moving any control on the interface doesn’t do anything at all. There is no change to the sound no matter what parameters are changed, including volume, pitch, filter cutoff, etc. Pressing the virtual keyboards on SEM V and Wurlitzer V result in notes playing, which is great, but none of the controls on any plugin alter the sound in any way. In every case, these controls work perfectly fine in the VST2 versions in my DAW.

In addition, here are other problems I’m seeing with these VST3 plugins:

Arturia Oberheim SEM V & Wurlitzer V:

  • Only mono output shown in graph editor, no MIDI input shown
  • Changing presets doesn’t work, triggers asserts in startGroupEdit() and finishGroupEdit()

u-he Podolski:

  • Controls do not visibly move in the interface (though the displayed values change)

  • Asserts on shutdown: Leaked Message, AttributeList objects

    I know that VST3 separates the editor interface from the processor interface, and it’s the responsibility of the DAW to shuttle messages between the interfaces. Is there something in “Plugin Host” that the user needs to implement that make these plug-ins work properly, that just isn’t implemented for demo purposes?

    One last question: VST2 plugins used a callback method to request information on tempo, time signature, playback state, and lots of other things. In Juce’s VST3 implementation, how do we pass tempo & time signature information to the VST3 plugin?


Hi Dan!

OK I’ve fixed this on the latest develop branch tip. As you probably know, it’s the plug-in’s responsibility to store the actual value of the parameter (in a float for example) and the plug-ins you mention do not update this internal value if the user changes the value in the custom UI of the plug-in. This is quite odd. In JUCE for example, you would typically call setParamValueNotifyingHost which changes the internal parameter value and then tells the host that it has changed to a new value. Podolski and the other plug-ins you mention, simply tell the host that the value has changed but do not update the value internally.

To fix this, I’ve now added an extra check in the host code which actually checks if the plug-in is still reporting the old value if it has told the host that the parameter has changed. If it is, we queue the parameter change and send to the plug-in’s processing callback.

This is a limitation of the audio plug-in host at the moment. I guess that SEM V & Wurlizter V will come up as a mono plug-in by default. The host demo does not support changing the layout.

This could be related to the workaround that I have implemented. Could you check if this works?

Works with the fix on develop mentioned above.

Podolski seems to be sending a message during shutdown. That’s really not a good idea as things are already half deleted. Luckily this will only cause some leaked memory. You should really report this to the developers.

No. The plug-in host fully implements the messaging infrastructure.

In VST3, the main process callback can take a HostContext parameter which includes this information. JUCE does supply this information via the audioPlayHead class.

The bad news: Asserts are still thrown in startGroupEdit() and finishGroupEdit(). This isn’t a surprise, really – the code in juce_VST3PluginFormat.cpp reads:

tresult PLUGIN_API startGroupEdit() override
    return kResultFalse;

…so all this does is throw an assert and return false.

The good news: It doesn’t seem to matter, because changing presets now works, as does turning knobs, etc. Well done!

Do you suppose you’ll be adding support for startGroupEdit/finishGroupEdit in the future?

I can do that, sure. What message is being sent on shutdown, how can I tell?

Excellent, I’ll explore this. Thanks so much for your help!



I’ve noticed that calling reset() on a VST3 does not cause the plugin to flush its buffers as expected. Is there a mechanism in Juce’s VST3 implementation that can be used to flush the buffers of a VST3 plugin?