VST Host Best Practices?

Is there a consolidate list of “best practices” for how a hosts should handle VST plugins?

I seem to recall it was advised that plugins be initialized (prepareToPlay) from the message thread or else some plugins would misbehave, is that right?

Are there any other tips of tricks to this?

You should create/initialise the plugin from the message thread, but that only happens once, and prepareToPlay can (and should) be called from the audio thread.

Jules if you don’t mind could you explain why plugin initialization should happen on the message thread? I’ve read this before (on the forum here or elsewhere) but I’m having a hard time finding documentation around it. I currently have plugins loading on a background thread and it seems to work ok. Also, you mention that prepareToPlay should be called from the audio thread but in AudioProcessorGraph the nodes are prepared in buildRenderingSequence, which isn’t called on the audio thread, and certainly you wouldn’t want it to be as it takes some time to build. Could you provide further thoughts on that as well?


Well, it’s only important on win32, because a HWND is owned by the thread that creates it. So if your plugin never gets a chance to create a HWND on the event thread, then it’s not possible to create a HWND that has its messages delivered to it by the event thread. Some plugins don’t need to create HWNDs or send messages, but many do (including all juce ones).

I never managed to find a workaround for this from the plugin’s side.

Oh! Well that makes sense. An HWND is attached to the message queue of the thread that created it. You’re right, there’s no workaround for that.

Looks like it’s time to turn off my background thread. Thanks for explaining it!

Wow Jules… I must say, the JUCE audio plugin hosting code works great when you…actually create the plugin from the message thread!!!

It appears that when I load some VST plugins in the message thread (win) and starts playing right away, there is a delay in the position line in my sequencer
(the audio itself is ok)

I believe this is because those VSTs need some GUI setting time, when I’ve added runDispatchLoopUntil(100) the delay was gone.

Is there a way to get an indication as to whether the plugin is done loading ( the AudioProcessorListener’s callbacks currently does not provide such info)

It makes good sense, but Juce Plugin Host calls my VSTs prepareToPlay on the message thread!

When I said “should”, I only meant that your app will probably run more smoothly if it calls it on the audio thread, rather than blocking the UI thread to do it.

As long as the prepareToPlay call doesn’t overlap any process calls, it doesn’t really matter which thread does it.

I know this is an old thread, but my question is about this. If I´m hosting multiple VSTs from a Juce VST Plugin, how do I handle the messages thread?

Thanks! 8)

Your best bet is to trigger creation of “subordinate” plugin instances (and destruction, of course) from the editor.
Since the editor is required to be entangled with the host’s message loop, it’s the natural place to go.

But what if a project is open and the editor doesn´t get open?