Plugin-editors still redraw even when closed on M1/Logic

Audio Plugins
1

I just discovered, if a m1-native plugin editor is closed in Logic, it still gets regularly repainted (acts exactly like if it was never closed) which of course is a massive waste of cpu time (especially if you have some costly visualisation). I’m not sure what the reason is and if its specific to JUCE Plugins.

2

As this is potentially a very major issue, I looked into this instead of just waiting for the JUCE team to react. I added logging to my editor class and found that the Logic Pro X version I have access to (10.6.0) does indeed not destroy the editor when closing the plugin GUI window on my m1 mbp. My code depends on that and now unnecessary calculations are happening once the GUI has been open. The editor only gets destroyed once the plugin is removed from Logic.

Update: I also tried calling getActiveEditor()->isVisible() from my processor, but it keeps returning true. It seems we have no way to know whether our editor is visible or not.

Just to be sure I also ran the logging code in Reaper Beta for arm64 and AULab.app and everything works fine there. It does feel like a bug in that Logic Pro X AU hosting process that also makes debugging very hard.

2 Likes
3

If I override viewDidAppear and viewWillDisappear in the AUViewController of Apple’s AUv3FilterDemo plugin, I see that these functions are only called when creating and destroying the plugin instance respectively.

I also tested with a JUCE plugin, and it seems that Logic creates the editor and then keeps it around for the entire lifetime of the plugin.

Given that the behaviour is the same for both JUCE and non-JUCE plugins, I suspect this is just the way that Logic handles out-of-process hosting. I don’t think there’s much we can do to work around this in JUCE.

4

Is there some way (in JUCE) to know if the plugin window is actually visible or not?

5

I don’t think so. If we wanted to ask the OS whether the view is visible, we’d probably use isHiddenOrHasHiddenAncestor, but this appears to return false whether or not the plugin window is currently showing.

6

Maybe you could get in touch with someone at Apple? If it comes from the JUCE team, I think there’s a better chance of getting noticed.

7

Have done, their engineers are aware of the issue.

6 Likes
8

isVisible() simply returns what has been set with setVisible(). Instead, to gain information about whether a Component is hidden because a parent/container is, you should check with isShowing() (but I don’t know if it’s implemented correctly for this case scenario, just a shot in the dark)

1 Like