Ok, I finally got myself a copy of wavelab, gritted my teeth and debugged this. After a lot of swearing, I’ve found a solution that works, and it’s checked in - please have a go and see if you still have any problems.
Their idiotically unpredictable threading model makes it impossible to find out which thread will actually be delivering messages - it doesn’t even seem to be the main thread that does it. So the only workaround is simply to make the message manager switch to the thread that gets used to open the effect’s window. God knows if this is actually thread-safe because I’ve no idea whether their threads are locked against each other or not, but it seems to work.
An annoying but unavoidable side-effect of this is that events that get posted in your plugin’s constructor or your UI’s constructor may be lost when the messaging system has to restart itself shortly afterwards. So things like asyncupdaters could appear to get stuck because they’re expecting a message to arrive that was thrown away. This is probably quite a rare thing to happen, but if you do get puzzled by something not working in wavelab, this might be the reason.
Despite using all of the new code from the git tip (Juce & Wrapper) and fixing some obvious triggerAsync-in-constructor issues in my own code, I am still having a lot of thread related problems in Wavelab (on Windows 7).
Sorry, I was a bit vague. I’m not suggesting that the problem lies with Juce - I could be doing something wrong. I use a lot of my own thread management code, mixed with the Juce stuff. I haven’t got a simple test-case or anything. I might have some time to look at this again in a few days time. Thanks.
After a long pause, I’ve come back to retake my VST implementation. I was reading last news and I saw the good news about Wavelab compatibility. IT WORKS!
Thank you, thank you, thank you!
Just only reimplement 1.51 libraries retouch JucePluginCharacteristics.h, and in less than a quarter of hour, my plugin did work in Wavelab. You are the best Jules!
Thank you again!
Gabriel
[quote=“jules”]Ok, I finally got myself a copy of wavelab, gritted my teeth and debugged this. After a lot of swearing, I’ve found a solution that works, and it’s checked in - please have a go and see if you still have any problems.
Their idiotically unpredictable threading model makes it impossible to find out which thread will actually be delivering messages - it doesn’t even seem to be the main thread that does it. So the only workaround is simply to make the message manager switch to the thread that gets used to open the effect’s window. God knows if this is actually thread-safe because I’ve no idea whether their threads are locked against each other or not, but it seems to work.
An annoying but unavoidable side-effect of this is that events that get posted in your plugin’s constructor or your UI’s constructor may be lost when the messaging system has to restart itself shortly afterwards. So things like asyncupdaters could appear to get stuck because they’re expecting a message to arrive that was thrown away. This is probably quite a rare thing to happen, but if you do get puzzled by something not working in wavelab, this might be the reason.[/quote]
