Juce incorrectly calling IComponentHandler::performEdit from audio thread

I’m currently working on VST 3 hosting support in my app (Cantabile), and noticed that Juce plugins are incorrectly calling IComponentHandler::performEdit from the audio thread.

Take a look at this call stack:

Now see this post on the VST 3 Developer Forum where I asked about this and Yvan Grabit explicitly states this is not allowed.

Also, for reference, see also this post for detailed break down of parameter handling in VST 3 plugins.

1 Like

Oops, you can ignore this. I jumped the gun and didn’t notice this is probably the fault of the sample code I was testing with (and didn’t properly understand). Sorry about that.


Perhaps to help prevent other devs from making this mistake, Juce could assert if the setValueNotifyingHost() method is called on a non-UI thread. Either that or make it work by posting to the UI thread and calling the host from the correct thread.

1 Like

On this post, @jules says:

Yes, I think it’s ok to do it from any thread.

If setValueNotifyHost is calling performEdit then this statement is definitely not true and you should only call it from the main UI thread.

According to this post (see Yvan’s response to point 4) on the VST dev forum one way to send parameter changes to the host from the audio thread is via the outputParameterChanges collection passed to the process call.

1 Like

Yes, that’s something we’re doing wrong in JUCE. We’ll have a look at it.

2 Likes