# Logic Pro: Plugin Editor Destructor not always called on window close

**URL:** <https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865>\
**Category:** General JUCE discussion\
**Created:** [February 3, 2023, 5:29pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865 "2023-02-03T17:29:47Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 3, 2023, 5:29pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/1 "2023-02-03T17:29:47Z")

</div>

We’ve got a very peculiar bug with our JUCE plugin in Logic Pro.

In some situations, when the user closes the Plugin Editor, the destructor of our `juce::AudioProcessorEditor` does NOT get called. After this has happened, if we reopen the plugin, the constructor of our `juce::AudioProcessorEditor` does NOT get called. Yet, the plugin UI does appear on screen and mostly work (with some broken parts). We verified this behavior in Logic with a debugger.

This behavior does not happen all the time. Usually we get regular constructor/destructor calls for plugin window open/close. But certain actions in our UI seem to trigger this no destruct/construct behavior occasionally.

Is it valid for Logic Pro to NOT destruct your Plugin Editor when you close the plugin editor window? Has anyone else ever experienced this behavior?

I am aware that DAWs will sometimes call the constructor/destructor multiple times before fully opening a plugin editor, but I have never heard of a DAW keeping your plugin editor alive even when you close the plugin window.

**We’ve got a hunch that Logic may not be the culprit here, and that maybe we have a smart pointer keeping our Plugin Editor alive longer than it should be.**

But as I am investigating, I was wondering if anyone else had ever experienced this with Logic specifically.

Thanks!

Specs:  
Apple M1, JUCE 6.1.6

---

<div class="post-metadata">

**Author:** ![HowardAntares](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/howardantares/32/4629_2.png) [@HowardAntares](https://forum.juce.com/u/HowardAntares)\
**Post date:** [February 3, 2023, 6:14pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/2 "2023-02-03T18:14:12Z")

</div>

I don’t know of any requirement that the editor component be destroyed when closing the editor window. That seems to be the norm, but it’s up to the host, as far as I know. But to the point with Logic, I don’t recall ever seeing this behavior of it _not_ destroying our editor.

---

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 3, 2023, 6:15pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/3 "2023-02-03T18:15:09Z")

</div>

Thanks for the feedback. That’s good to know.

---

<div class="post-metadata">

**Author:** ![zabukowski](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/zabukowski/32/507_2.png) [@zabukowski](https://forum.juce.com/u/zabukowski)\
**Post date:** [February 3, 2023, 6:49pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/4 "2023-02-03T18:49:33Z")

</div>

True, Logic is not always deleting editor, i’ve seen that with our plugins. Live and Bitwig also expose similar behaviour, also on windows.

I think the problem in Live/Bitwig is that editor is preserved only with 1st plugin closing. After that, it’s working as usual, properly creating and destroying editor.

Anway, in my case, I added timer, which is constantly checking editor visibility, because there is no guarantee, that destructor will be called, when plugin editor is closed.

Check this post:

> [@Logic doesn't destroy the editor when it is closed?](https://forum.juce.com/t/logic-doesnt-destroy-the-editor-when-it-is-closed/52849):
>
> 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 …

---

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 3, 2023, 7:54pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/5 "2023-02-03T19:54:58Z")

</div>

What exactly are you doing with the timer if it determines the editor is actually invisible?  
Are you manually killing off the PluginEditor?

I’m still not sure that our code is not the culprit here instead of Logic.  
But you do say you have seen this same behavior. I just wonder if we actually have the same error in our code.

---

<div class="post-metadata">

**Author:** ![HowardAntares](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/howardantares/32/4629_2.png) [@HowardAntares](https://forum.juce.com/u/HowardAntares)\
**Post date:** [February 3, 2023, 9:10pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/6 "2023-02-03T21:10:59Z")

</div>

Our Processor components never explicitly address their Editor components in any way at all. All Editor-related work is done via the Editor component querying the Processor for information it needs during a timer callback in the Editor itself. We always assume that the Editor may or may not exist at any given time. That’s the only true safe way to deal with it, I would think.

---

<div class="post-metadata">

**Author:** ![zabukowski](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/zabukowski/32/507_2.png) [@zabukowski](https://forum.juce.com/u/zabukowski)\
**Post date:** [February 4, 2023, 7:19am UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/7 "2023-02-04T07:19:38Z")

</div>

In my specific case, when editor is closed, i have to remove some other top level windows (hosted plugins) from screen and vice versa. If editor would be properly destroyed, those windows would be automatically destroyed, too.

---

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 16, 2023, 6:07pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/8 "2023-02-16T18:07:32Z")

</div>

After investigating this issue further, we were able to prevent the behavior of Logic Pro where the PluginEditor is sometimes not destroyed when it is closed.

In our case, we found that calling `juce::Component` methods, such as `setVisible()`, `setBounds()`, `setPosition()`, etc, from within any `Component::paint()` function caused Logic to not destroy the plugin editor when it was next closed.

**Side Note:** We are using OpenGL to render JUCE Components, so since `paint()` is called by the OpenGL thread in this case, the Component calls in `paint()` could’ve been data races on Component data with the JUCE Message Thread. (We were getting threading warnings for these calls in XCode but only when testing Audio Unit in Ableton. Removing these Component method calls from inside the `paint()` function resolved these threading warnings.)

Additionally, we found that closing any `juce::PopupMenu` causes the PluginEditor not to be destroyed when the editor is next closed in Logic Pro (AU). Specifically in `juce_PopupMenu.cpp` in the function `PopupMenuCompletionCallback::modalStateFinished` the call to `toFront()`:

```auto
if (auto* topLevel = focusComponent->getTopLevelComponent())
    topLevel->toFront (true);

```

causes the PluginEditor not to be destroyed when it is next closed. Commenting out these lines resolves the issue.

Digging deeper, the specific cause of the closing Popup issue is found in `juce_mac_NSViewComponentPeer.mm` in `NSViewComponentPeer::toFront()`

```auto
if (makeActiveWindow)
    [window makeKeyAndOrderFront: nil]
else
    [window orderFront: nil]

```

both the lines which call window methods `makeKeyAndOrderFront` and `orderFront` trigger the unexpected behavior in Logic Pro, but only when these methods are called on the Top Level Component (plugin editor window) as seen in `PopupMenuCompletionCallback::modalStateFinished` callback.

This indicates to me that this behavior of Logic should NOT be expected as prior posts in this thread have indicated. Maybe this is a bug in Logic, or some kind of unspoken Audio Unit rule that you should not modify window ordering in Logic? We already know that Logic dislikes AUs spawning additional windows, hence the magenta tinting on transparent parts of PopupMenus that are shown outside the PluginWindow:

> [@BUG? Popup Menu Background and Logic Silicon](https://forum.juce.com/t/bug-popup-menu-background-and-logic-silicon/43243/17):
>
> Ok, I finally have a full answer and will update the ProAudio Seed Release Notes accordingly. Please check them regularly. Windows opened by the plugin might have a subtle magenta tinting. This is security feature, not a bug. It avoids that malicious code can open a window which overlays system windows. There are a couple of ways to avoid this tinting: Make the window less transparent (75% or more opacity will avoid this tinting) Call -[NSWindow addChildWindow:…]. This will confine the magent…

Similarly, maybe Logic dislikes ordering (e.g. `orderFront`) of Audio Unit windows and prevents the PluginEditor from being destroyed because ordering windows insinuates the AU may have multiple windows?

Note: I am using JUCE 6.1.6 and have not tested with the latest JUCE. I have verified at least that the code I reference relating to `PopupMenu` and `NSViewComponentPeer` still exists in JUCE 7.0.5.

@reuk Have you ever seen behavior like this in Logic Pro (or any other DAW)? As a JUCE plugin dev, should I assume it is legal for any DAW to NOT destroy my `PluginEditor` when the editor window gets closed? Thank you for any insight!

---

<div class="post-metadata">

**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\
**Post date:** [February 17, 2023, 10:12am UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/9 "2023-02-17T10:12:04Z")

</div>

> [@timart](#):
>
> calling `juce::Component` methods, such as `setVisible()`, `setBounds()`, `setPosition()`, etc, from within any `Component::paint()`

AFAIK this is considered bad design and should be avoided: in `paint()` you should only draw the current state of whatever needs to be painted, but no changes to UI elements should happen there.  
As a rule of thumb, inside `paint()` you should only call methods that are marked `const` in `Component` and its subclasses.

---

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 17, 2023, 4:00pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/10 "2023-02-17T16:00:01Z")

</div>

Good to know, thanks! We had realized we were getting infinite paint loops due to our calling Component methods like this in the paint function. For example, our paint() method might call setVisible() on a child component which could trigger a repaint() which would call paint() and repeat. I am surprised that JUCE docs for `Component::paint()` do not warn about this as I think it is easy for beginners (and me when I am not thinking) to make this mistake.

Besides this issue, I am still surprised Logic Pro does not call the destructor of the PluginEditor after you have closed a PopupMenu and then close the plugin window (detailed in prior post).

It would be helpful to know if we should expect a DAW to NOT destroy a `PluginEditor` when it is closed.

In my case, we are using some custom OpenGL components, and knowing the answer to this question would influence how we initialize these custom OpenGL components (either via constructors or via only `newOpenGLContextCreated()`).

---

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 17, 2023, 5:20pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/11 "2023-02-17T17:20:03Z")

</div>

I wrote a test to confirm the PopupMenu problem does exist in JUCE 7.0.5 (master branch in git).

For Audio Units running in Logic Pro on Apple M1 macs, if you close any juce::PopupMenu, the next time you close the plugin editor, the `juce::AudioProcessorEditor` destructor will NOT be called. The usual behavior is that when you close the plugin editor, it calls the destructor of `juce::AudioProcessorEditor`.

Here’s a repo with code that reproduces the issue:

> **[GitHub - TimArt/JUCELogicAUPopupMenuDestructionGlitch](https://github.com/TimArt/JUCELogicAUPopupMenuDestructionGlitch)**
>
> Contribute to TimArt/JUCELogicAUPopupMenuDestructionGlitch development by creating an account on GitHub.

In this test plugin, I have a button that opens a popup menu, a label that shows the time of construction, and a label that shows the current time.

**Expected Logic Behavior**

1. Open the plugin
2. Take note of the Construction Time value in the top left.
3. Close the plugin (make sure you do not open/close the popup menu)
4. Reopen the plugin
5. Notice the Construction Time has changed.

In this sequence, Logic properly destroys and reconstructs the `juce::AudioProcessorEditor`.

**Unexpected Logic Behavior**

1. Open the plugin
2. Take note of the Construction Time value in the top left.
3. Click the button to open the `PopupMenu`
4. Either choose an option in the `PopupMenu` or close the menu by clicking outside of it.
5. Close the plugin (make sure you do not open/close the popup menu)
6. Reopen the plugin
7. Notice the Construction Time has NOT changed. It is the same construction time from last plugin open.

In this sequence, Logic does NOT call the destructor of `juce::AudioProcessorEditor` when the plugin window is closed, and does NOT call the constructor of `juce::AudioProcessorEditor` when the plugin window is reopened.

This can be confirmed by placing breakpoints in XCode, assuming you disable macOS SIP to debug in Logic.

In my prior post, I explain the code that triggers this behavior in Logic:

> [@timart](#):
>
> Digging deeper, the specific cause of the closing Popup issue is found in `juce_mac_NSViewComponentPeer.mm` in `NSViewComponentPeer::toFront()`
> 
> ```auto
> if (makeActiveWindow)
> [window makeKeyAndOrderFront: nil]
> else
> [window orderFront: nil]
> 
> ```
> 
> both the lines which call window methods `makeKeyAndOrderFront` and `orderFront` trigger the unexpected behavior in Logic Pro, but only when these methods are called on the Top Level Component (plugin editor window) as seen in `PopupMenuCompletionCallback::modalStateFinished` callback.

---

<div class="post-metadata">

**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\
**Post date:** [February 17, 2023, 5:41pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/12 "2023-02-17T17:41:31Z")

</div>

> [@timart](#):
>
> The usual behavior is that when you close the plugin editor, it calls the destructor of `juce::AudioProcessorEditor`.

That might be the usual behavior, but the DAW is not _required_ to behave that way.

It’s perfectly fine for it to keep your editor instance upon close and simply hide it, then show it again the next time it is asked to display the plug-in window for that plug-in instance (in which case, it is not required to call its constructor either, because it was already constructed the first time you used it, and not destructed when hiding).

The only requirement I am aware of, is that the DAW must make sure that the editor window doesn’t outlive the plug-in instance.

Brought to the extreme (maybe there are DAWs out there that work that way), the DAW may even keep your plug-in _processor_ alive when you remove it from a track, and for example destroy it later on with a “garbage collection” mechanism.

In a similar situation, the plug-in processor and its editor may remain in memory far longer than their presence in the DAW UI might suggest, but still that would be conformant, as long as everything is cleaned up by the time the DAW is quitted.

---

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 17, 2023, 6:00pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/13 "2023-02-17T18:00:32Z")

</div>

Thank you for your feedback! This is good to know and your claims match what I’ve heard from other JUCE devs. It is probably best that I make sure my code works even in the scenario where the DAW chooses not to destroy the editor when the window is closed.

Regardless, I think it is very peculiar that windowing methods `orderFront` and `makeKeyAndOrderFront` can cause this behavior consistently in Logic Pro. This may just be the way that Logic works, but **I am curios if Logic actually does not want us to be calling these methods.**

The two forum threads linked below do indicate that Logic does not want AUs to use multiple windows. I wonder if the no-destruction behavior I am observing in Logic is a response to code that deals with multiple AU windows.

> [@Major window handling issues with Logic/ARM](https://forum.juce.com/t/major-window-handling-issues-with-logic-arm/53755/20):
>
> I had a quick look today and still didn’t really get anywhere. It seems that the [official Apple guidance](https://developer.apple.com/documentation/audiounit/debugging_out-of-process_audio_units_on_apple_silicon?language=objc) is “don’t open secondary windows in AU plugins”. If they’re not really testing or supporting this use-case, then unfortunately I don’t think that we can.

> [@BUG? Popup Menu Background and Logic Silicon](https://forum.juce.com/t/bug-popup-menu-background-and-logic-silicon/43243/17):
>
> Ok, I finally have a full answer and will update the ProAudio Seed Release Notes accordingly. Please check them regularly. Windows opened by the plugin might have a subtle magenta tinting. This is security feature, not a bug. It avoids that malicious code can open a window which overlays system windows. There are a couple of ways to avoid this tinting: Make the window less transparent (75% or more opacity will avoid this tinting) Call -[NSWindow addChildWindow:…]. This will confine the magent…

---

<div class="post-metadata">

**Author:** ![mfritze](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mfritze/32/9008_2.png) [@mfritze](https://forum.juce.com/u/mfritze)\
**Post date:** [February 20, 2023, 11:59am UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/14 "2023-02-20T11:59:03Z")

</div>

“Logic does not want” is a strange statement. The tinting for example is a security feature, which was designed by the macOS Team and implemented inside macOS. Logic has nothing to do with it and can’t do anything about it. This feature exists to prohibit malicious code from overlaying windows of other applications to potentially steal inputs (e.h. passwords).

The multi-window issue: I am not sure about the technical reason for it, but under Apple Silicon all AudioUnits are no longer part of the Logic process (for security, privacy and also stability reasons) and mapped into the plugin window of Logic by “macOS magic”, similar to the file selector having access to the whole file system, even if the application presenting it does not. It might be a bug or limitation of this process behavior or it might even be a subtle bug in the AudioUnit, which triggers macOS to keep a reference to the window around, which results in it not being destroyed when closed. I simply do not know.

---

<div class="post-metadata">

**Author:** ![timart](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/timart/32/1119_2.png) [@timart](https://forum.juce.com/u/timart)\
**Post date:** [February 20, 2023, 3:41pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/15 "2023-02-20T15:41:19Z")

</div>

Thank you very much for your feedback! It is great to hear from you directly on this.

It is good to know there is not a known rule we are violating by using windowing methods `orderFront` and `makeKeyAndOrderFront`. Also, thank you for the extra info on the magenta tinting. Good to know it is a macOS wide feature.

Based on what I’ve heard in this thread, **as JUCE plugin developers, we should expect the scenario where a DAW chooses not to destroy a PluginEditor even when the window is closed**. This behavior can be tested for in Logic (10.7.7 on M1) by opening/closing a Popup menu then reopening the plugin editor (in JUCE 7.0.5).

If your plugin is using custom OpenGL components, you may see visual glitches in this scenario (e.g. all custom OpenGL components are black). When a non-destructed plugin window is made visible again, the PluginEditor does not get constructed again, yet the OS may decide to provide a new OpenGLContext to be used on reopen. If you trigger the initialization of custom OpenGL programs from the constructor of your PluginEditor, then the OpenGL initialization would not happen in this scenario resulting in black components. Make sure all OpenGL initialization is triggered via `OpenGLRenderer::newOpenGLContextCreated` as this method gets called in this scenario even when the constructor is not called.

---

<div class="post-metadata">

**Author:** ![papakos](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/papakos/32/16926_2.png) [@papakos](https://forum.juce.com/u/papakos)\
**Post date:** [July 19, 2024, 8:15am UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/16 "2024-07-19T08:15:44Z")

</div>

Still the case for me with Logic Silicon JUCE 7.0.10

---

<div class="post-metadata">

**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\
**Post date:** [July 19, 2024, 7:04pm UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/17 "2024-07-19T19:04:51Z")

</div>

Does it still happen in Juce 8.0.x? that was released recently…

---

<div class="post-metadata">

**Author:** ![papakos](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/papakos/32/16926_2.png) [@papakos](https://forum.juce.com/u/papakos)\
**Post date:** [July 23, 2024, 8:10am UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/18 "2024-07-23T08:10:15Z")

</div>

Unfortunately we don’t have a JUCE 8 license

---

<div class="post-metadata">

**Author:** ![anthony-nicholls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/anthony-nicholls/32/1246_2.png) [@anthony-nicholls](https://forum.juce.com/u/anthony-nicholls)\
**Post date:** [July 23, 2024, 8:23am UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/19 "2024-07-23T08:23:14Z")

</div>

As long as you’re not distributing anything you can still test with JUCE 8. That being said it seems unlikely anything has changed. From what I can tell from this thread it seems within reason that that this is not a JUCE bug and therefore there may be very little we can do about it. Is there a reason that you can’t handle the case that the editor wasn’t destroyed when the window was closed?

---

<div class="post-metadata">

**Author:** ![papakos](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/papakos/32/16926_2.png) [@papakos](https://forum.juce.com/u/papakos)\
**Post date:** [July 23, 2024, 9:07am UTC](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865/20 "2024-07-23T09:07:38Z")

</div>

We are using a modal for authentication and I think that’s what seems to break. The modal is no longer listening to any keystrokes after the plugin UI is opened, without having been destroyed beforehand.  
There are two workarounds, one is to remove the plugin completely and add it again to the relevant Logic track and the other is to click _Window → Hide all plugin windows (V)_. Then opening up the plugin window seems to work again properly.

[Next page](https://forum.juce.com/t/logic-pro-plugin-editor-destructor-not-always-called-on-window-close/54865.md?page=2)