The user also reported other JUCE plug-ins from other companies that have the same issue. I think it’s a general problem between JUCE and Logic X in Tahoe. Probably some changes in the Window or Event handling lead to this. @reuk
So if the binary is from 2023, what’s to say this hasn’t already been fixed in the last 2 years? What’s the expectation here? Have you tested this yourself with more recent builds?
I was probably not clear enough. The problem happens with JUCE 7 plugins (or even older) and also with 8.0.10 builds. There is a big chance that your plugins are also affected on some systems.
We’ll see how it goes. Maybe the issue will be quietly fixed with a Logic or macOS update, and no one cares. I just wanted to report this to see if others have noticed it as well and find out more about it.
I reported the dead-zone issue to Apple in September via the feedback app and on request provided a simple test plugin that displays the mouse coordinates when clicking which stops responding to clicks in the dead zone. I have not heard back since I submitted the care package.
You may notice that if you change the length of the plugin name the width of the dead zone changes proportionally. It also affects FabFilter products (Pro Q4 has a little button in that region that is partially non-functional). I’m not sure if those use Juce but I have a hunch they don’t, it would be good to know one way or the other though as that might rule Juce out.
We also reported a dead zone issue to Apple when using the “collapse” button in the top right of the Logic hosting window. The top area of the plugin corresponding to the difference in height between the full and collapsed Logic bar becomes inaccessible. We observed this with non-JUCE plugins as well, so I think it’s an Apple/Logic bug.
It also only seemed to happen in macOS Tahoe on Arm, running under Rosetta it doesn’t appear.
That’s interesting, I had not noticed it at the top as well but yes I do have this too when I reduce the hosting window frame size with the button that hides the upper elements. In my test plugin the dead zone is related again to the width of the adjacent text, this time the track name which appears at the top of the plugin container window (it’s much easier to change the width of that text of course by changing track name than renaming the plugin binary to test the effect at the bottom).
I’ve experienced the behavior where the entire window becomes unresponsive to mouse events as @kunz describes in the original post. It is very reproducible and affects many plugins from many publishers.
I don’t know what the root cause is, but it only seems to occur when the plugin stops painting for a period of time. This may at least partially explain why some have not experienced it: if a plugin repaints meters, for example, even when the underlying metered value is unchanged, then this behavior would seem not to occur. Ironically, plugins that are more diligent about eliding unnecessary painting will suffer more.
Consequently, one hacky work-around that I can attest to is to create a dummy component that repeatedly paints a single transparent pixel. This appears to ensure liveliness, icky though it is.
So far I’ve not been able to reproduce the issue with:
macOS 26.5 Arm
Logic 12.2
tal-chorus-lx 1.6.3
Please could you provide as much detail as possible about the situations where the issue manifests?
What plugins, specifically, cause problems? (Please include version numbers)
What Logic version? Native, or using Rosetta?
What macOS version? Arm or Intel?
What steps are involved to reproduce the problem? e.g. is the issue still triggered by moving the plugin editor window with the mouse?
I wonder whether you’re able to produce the same problem with any of the Apple system audio units such as AUGraphicEQ or AUDistortion. If the issue is present for those plug-ins, then the bug is almost certainly in Logic or the OS, and should be reported to Apple.
Not an exhaustive list by any stretch, but I can quickly repro on
UA’s LA-3A (v1.0.15)
IK’s Comprexxor (v6.3.0)
Plugin Alliance’s bx_limiter (v1.16.1)
SSL’s Fusion Vintage Drive (v1.3.2)
and yes, even Apple’s own AUDistortion (the plot thickens… or maybe thins)
And can repro on at least:
Logic 11.2.2 and 12.2
macOS 26.4.1 and 26.5
arm64 arch
To reproduce:
Create a new and empty project in Logic
Create a new track with no input and no output (for minimal re-paint, see my previous post)
Add a plugin to the created channel under the usual “Audio FX” section
Vigorously move the plugin editor window as seen in OP’s video
Invoke mouse events in plugin editor (e.g. click on UI controls, invoke mouse-over behavior, etc.)
Observe erroneous behavior: no mouse events occur
As I previously mentioned, the issue seems definitely related to paint updates. Any visual updates to the plugin editor UI prevents (or resolves?) the issue. Even painting a single black or alpha-zero pixel at regular intervals works around. It’s as though mouse focus is lost and is not regained until a repaint occurs. But whether it’s the paint or some side-effect of painting that allows (or restores?) mouse events, I can’t say.
Seems to randomly happen when moving any of our AudioUnit plugins around in Logic or GarageBand (only). Only in Tahoe. Funny thing is, clicking anywhere owned by the DAW fixes it, including moving the window again. Makes it hard to debug when clicking anywhere else fixes it. I tried to breakpoint on various mouse event callbacks, assuming it was a simple matter of x/y offset, but nothing gets called once this happens. No enter/exit, hit test, mouse down/move/drag/up. Nothing.
Thanks, I was able to repro now using the AUDistortion, and moving the mouse/window very quickly. I can’t get it to happen consistently, initially maybe one time in 10, but getting it to happen once seems to make it easier to trigger repeatedly. For me, moving the mouse over the “Manual” dropdown at the top of the window seems to restart painting again.
Given that this affects Apple Audio Units, I strongly suspect this is a bug in Logic or in the view hosting layer, so I’d recommend reporting it to Apple directly.
It’s undeniable that the breaking change came from Apple. Hopefully this is a bug and not some intentional optimization they’ve added to elide mouse hit-testing. Or at least if it is, it would be nice to know what the proper way to enforce liveliness is.
Something perhaps related and interesting: QuartzDebug no longer functions properly in Logic to flash repaint regions. QuartzDebug now just shows the entire window region as being constantly repainted (which I have verified is definitely erroneous). I don’t think I’m imagining that this used to work. I wonder if there is some overlay that Logic places on top of the plugin editor that is causing both of these issues.
