Displaced GUI in VST (OS X)


when VSTs on OS X get resized shortly after creation, the plugin GUI is displaced to the host window (see attached png). This only happens with 32-bit VSTs and it doesn’t seem to happen when loading the plugin the first time (but also after reopening the GUI). I was able to reproduce this behavior with a modified JuceDemoPlugin’s GUI. I attached the .h/.cpp files as zip (actually .pdf as the forum won’t allow .zip file attachments; please rename after downloading). All it does is resize the GUI randomly in the first timer callback.

This occurs in Reaper and Studio One but not in Cubase. As it happens only with 32-bit VSTs I assume that the resize while initiating the GUI might mess up the Carbon GUI overlay.

Any ideas how this can be fixed?
Is it maybe possible to force the GUI to use Cocoa or are there still hosts out there that need Carbon?

Our plugin’s size depends on the plugin’s settings, so it is necessary to adjust the GUI size after the state has been set which will be after the AudioProcessorEditor’s constructor has finished.


Nobody any ideas? If the issue itself is too rare maybe someone can comment on forcing a Cocoa GUI from the plugin side for VST.

As having to rename a file to get a zip file I added the source files with an additional ".txt" to this post.

Hmm, sounds like a very obscure one.. As a workaround you might want to try waiting until your paint() routine has been called before attempting a resize - could be that resizing before the host has had chance to actually get the window on-screen is confusing some hosts.

Is it maybe possible to force the GUI to use Cocoa or are there still hosts out there that need Carbon?

no - I'm afraid it all depends on whether it's a 32 or 64 bit build.

Thanks for the response.

Waiting for paint doesn't seem to help. In the DAWs I tried, you actually see the GUI being created somewhere else and then jump to the plugin host window. This for example also happens in Cubase which on the other hand doesn't show the displacement behavior.

I will try a bit further and let you know if I find anything.

I was able to fix this issue by calling updateComponentPos in EditorCompWrapper::resized():

void resized()
  Component* const editor = getChildComponent(0);

  if (editor != nullptr)
    editor->setBounds (getLocalBounds());

#if JUCE_MAC && ! JUCE_64BIT

Beside the above change, updateComponentPos needs to be made available by removing the static in its definition and adding an external declaration in juce_VST_Wrapper.cpp.

Here’s a private video showing a similar issue using the tip Host demo and the JUCE demo plugin…

You’ll notice the problem only happens if you have another plugin open (which doesn’t have to be a JUCE based plugin)

Also, if another plugin is open and you drag the demo plugin around the redraw causes the UI to flash white.


Much appreciated, I'll take a look at this asap!

…should have mentioned… this only happens in the demo host on OSX



I've implemented ckk's suggestion above - let me know if it helps.

I’m still seeing the same behaviour with the tip on OSX


As i posted here:

I get this problem in Wavelabs. And I don't have to get other plugins actived. Just after starting wavelab I load some juce plugin and it happens while:
- dragging plugin window
- resizeing window
- reopening window

The worst thing is when I close wavelab and the plugin "guts" are floating on desktop for a while without window.

I wonder if it depends on VST wrapper.
In vst-gui we have Editor constructor and function Open in CFrame. We don't allocate memory for sliders in constructor, but in Open function. So it is possible that host is make'ing a copy of Editor without opening it - what means without drawning anything.
I don't know how it is done in Juce, but we have only AudioEditor constructor which is very nice for developers to use :) , but maybe vst host like Wavelab is making copy of Editor, but without passing window pointer, because host wants to do it in Open function... 

Hi all,

I have the same issue with the 32-bit VST version in 32-bit build of PluginHost, and with the 32-bit RTAS version I occasionally get the floating "plugin guts" (i.e. seperated from the containing floating RTAS window) in Media Composer, which usually leads to a window-related crash.

I'm about to start digging into RTAS side of it, just joining in the discussion!




I found out, that the problem occurs even in REAPER.
When I double click on plugin name to make it flow in floating window - than as I grab the corner of the floating window - I can try resizing it so the plugin window is smaller, but the guts of plugin have still the same size... they are getting out of window. And after a while... they are floating !!