Logic doesn't destroy the editor when it is closed?

Hi all! I just ended the wildest debugging session which ended in the conclusion that Logic will under circumstances which are not entirely clear to me, not destroy the editor object when it is closed.

The editor continues to live - even renderOpenGL() is called while no editor is visible. When the editor is openened up again, newOpenGLContextCreated() is called, but never the destructor or constructor of the Component. This caused a lot of problems in my code, since shaders and stuff were not properly initialized at this point.

What’s more confusing is that I can provoke this behaviour by creating a “complicated” preset. Think an MSEG with thousands of control points will do the trick 99% of the time, while the simplest preset will trigger the issue hardly ever.

I’ve built a workaround so everything is reinitialized when the new context opens, but the entire situation leaves a bitter taste in my mouth. Is this normal behaviour?

JUCE 7.0.1
macOS Monterey 12.3, M1
Logic Pro 10.7.4 Trial

  1. On sandboxed (currently Apple Silicon), this UI still running in the background consuming resources. Apple has been reported about that.

  2. Recent head of develop actually includes some OpenGL fixes that looks and sounds related


Slightly related: Even on Intel, where AU plugins are not sandboxed I noticed that logic actually re-uses the very same memory when an editor is destroyed and re-created, I verified that by comparing the memory address of the editor when re-opening it multiple times. This might be related to Logic using its own malloc implementation.

This lead to a hard to track down uninitialized variable bug in one of our products recently, where the value of the uninitialized variable was always exactly the same as it was when the editor had been closed for the last time.

1 Like

Ok so I didn’t lose my sanity after all. Thanks for confirming!

This is exactly what I thought at first when debugging my issue. Are you sure the editor got destroyed in your case? The outcome of variables “remembering” their values would be somewhat identical. This is true only for variables which aren’t initialized during construction of course as you say.

What you’re describing seems so familiar that I wouldn’t be surprised if the issues were the same in the end. But then who knows…

1 Like

@TheWaveWarden Could you give me some insight into your workaround regarding initialization of OpenGL shaders?

I am currently dealing with the same issue you describe. I’ve got lots of custom OpenGL shaders. After closing the editor sometimes, the PluginEditor destructor will not be called. After this, reopening the editor will not call the PluginEditor constructor. In this state, my custom OpenGL UI appears black, while other JUCE-painted UI is fine. The OpenGL UI appears black because when the editor was reopened, the OpenGL thread pool in juce_OpenGLContext restarts and sends a openGLContextClosing() callback to all my GL components, so they get deallocated. But, since the constructor of PluginEditor is where I initialize my OpenGL shaders, etc., they never get recreated for this plugin open.

I wonder what location besides the constructor I should I be initializing my OpenGL shaders, etc?

Thank you for any help!

Should I do all OpenGL initialization in newOpenGLContextCreated(), leaving none of it to happen in the constructors of any juce::Components?

Yip, this is my workaround exactly!

1 Like

@timart @TheWaveWarden I am experiencing the exact same issue on my plugin, and,
trying to implement this workaround, but I’m using attachTo() function from openFLContext.

If I move this call to newOpenGLContextCreated() it does not work, only works in constructor of a component.

Any decent way to achieve this?


1 Like

I believe attachTo should not be called in newOpenGlContext created. I think it is fine to leave that in a constructor that is triggered from the main JUCE thread.

You just want to move any OpenGL-specific initialization into newOpenGLContextCreated such as shader code compilation, OpenGL specific allocations (glGenBuffers, glGenTextures, etc), initial uniform values. Then in openGLContextClosed you would deallocate any OpenGL data you reserved (glDeleteBuffer, etc).

Does that make sense?

@timart Thank you!

Yes, it makes sense to leave that in the constructor as it is required only once.
But other than that I don’t really have anything in the constructor then except for setContinuousRepainting() , and still experiencing system instability warning on LogicPro.

Is it possible that setContinuousRepainting() is the culprit?

Note – if I remove attachTo() from component constructor, I do not get Logic warning!

Pardon my limited knowledge about openGL, I’ve just started getting hands on this!

1 Like

It sounds like you may be dealing with a different issue than described in this thread. You mentioned:

The problem described in this thread is not a warning from Logic but rather a behavior of how Logic calls constructor/destructor.

But maybe you are dealing with both problems? Sounds like your issue may be OpenGL related. Maybe you are doing some stuff in your paint() functions that is very heavy for OpenGL to run?

It may be worth starting a new thread describing your specific problem with the instability warning.

If possible, simulating this behaviour would be a great test to add to pluginval…

1 Like