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

General JUCE discussion
8

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():

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()

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:

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!

1 Like