maybe a different topic, but you may also want to know that all 32 bit vst plugins based on juce seem to experience some flickering / mouse problems when running in the 32-to-64 VST Bridge (I just tried a few and they all have the same problem). Generally cubase 5 hangs when I try to close the plugin window.
Well, I’d never even heard of the 32-64 bit bridge before, so this is all new to me… I guess that it works by running a separate process and channelling the mouse/display to its own window, which would explain the threading problems and flickering, but I really don’t know what to suggest!
I’d like to dig out this thread as the same issue is happening when one runs a juce vst plugin with fst ( http://www.joebutton.co.uk/fst/ )
Apparently , with win32/juce_VstWrapper, the juce messageThreadId is set to the current thread id the first time the VST entrypoint is called . It is then later expected that the same thread is used for the EffEditOpen call. If it is not the case, many non-threadsafe things will happen (as the messagemanager is not locked during aeffeditopen), and everything finally deadlock during the addToDesktop(0) call that is made to create the vst editor HWND.
I’m wondering if it is fst which is at fault, of if is the juce_VstWrapper that is making dangerous assumptions ? Jules, what do you think ?
Well, the VST spec was never very clear about how exactly threads are supposed to be used, so most plugins make various assumptions, and it’s a common cause of bugs…
I’d have thought that expecting the ‘initialise’ and ‘open’ calls to be on the same thread doesn’t seem unreasonable, but if there are problems, then a workaround might be just call setCurrentMessageThread() again during the ‘open’ callback (which has to be the message thread if any win32 functions are going to work)…
Yes that is something I did try but it was not changing anything. However adding a
currentLockingThreadId = threadId;
into MessageManager::setCurrentMessageThread helped getting further (as all calls to isThisTheMessageThread are returning false if I do not do that)
However it is not enough , as the plugin is not receiving any timer message. The InternalTimerThread has been created at the very beginning of the plugin instanciation, called “triggerAsyncUpdate” and never receive the asyncupdate message.
I tried to put if (!MessageManager::getInstance()->isThisTheMessageThread()) {
shutdownJuce_NonGUI();
initialiseJuce_GUI();
}
in effEditOpen and that almost worked (the timer get sent, but the vst dies a bit later probably because of messages never received or something like that).
Do you think there is a solution or is it hopeless ? If it is hopeless, I think the juce_vstwrapper should display a message when it detects that the effEditOpen is not called from the messagethread, that may help future vst host authors to know that they should use the same thread for plugin instanciation and gui initialisation on win32 (I have been contacted by a host author who was having this problem with all juce-based plugins)
It does seem a bit hopeless… All I can think of is that we’d need to write some platform-specific equivalents of MessageManager::callFunctionOnMessageThread that can be used to safely call initialiseJuce_GUI(). Not too tricky on the mac, but harder on win32 where you need to create a message window to receive a message (and creating a window needs to be done on the message thread!)
If it’s just this one host, then I think it’s probably up to them to fix it - there must be a lot of non-juce plugins out there that also need to set up some messaging-related functionality before the UI appears.
