When opening the plugin GUI, Wavelab (tested with both 7 and 9) seems to shortly move the UI offscreen, which invokes NSViewComponentPeer::redirectWillMoveToWindow, which detaches the OpenGL context. Wavelab then moves it back to the screen but the OpenGL context stays detached…
Also filed at the bug tracker at https://github.com/julianstorer/JUCE/issues/120
Running on macOS 10.12 with latest JUCE (develop branch).
This can be reproduced in a slightly modified JUCE demo plugin (to use OpenGL):
Add the juce_opengl module via the projucer
Add an OpenGLContext context; member in JuceDemoPluginAudioProcessorEditor.
Add context.attachTo (*this); context.setContinuousRepainting (true); context.setRenderer (this); in its constructor and context.detach(); in the destructor.
Make the editor inherit from OpenGLRenderer and add empty void newOpenGLContextCreated() override {} and void openGLContextClosing() override {} methods.
Add void renderOpenGL() override { glClearColor (1.0, 0.0, 0.0, 0.0); glClear (GL_COLOR_BUFFER_BIT); } which paints a red background using OpenGL.
Remove its paint method.
Now the demo plugin, with its new red background, should look like this (screenshot in Logic):
The lack of red background here indicates that OpenGL isn’t used here…
I would really appreciate a response to this, as this seems to clearly be a JUCE bug - the OpenGL context gets detached in NSViewComponentPeer::redirectWillMoveToWindow as if the plugin implementor deliberately decided it doesn’t need to be attached, and when Wavelab brings the view back into a window there’s nothing there to reattach it… So calling detach is probably not a good work-around for the previous problem.
I wonder if the work-around for issue 88 can safely be reverted, as I’d prefer false assertions in debug than the plugins not working in Wavelab (or any other host that shares it behavior).
Thanks for those fixes Yair. So far it’s working for me (VST2 + macOS Sierra + WaveLab Elements 9 (VST3 does not work)). I’ll report any issues I run into.