macOS Tahoe / Logic X: Mouse not respond after moving Window

MacOSX and iOS
1

A user reported this and I was able to reproduce it even with our simplest plugin.

When moving the window, the plugin stops responding to mouse inputs. Only a click outside the plug-in window makes it work again.

The video shows the problem with one of the simplest plugins we have. The binary is from the year 2023.

It happens randomly. Some plugins are more affected. Probably depends on the UI load and complexity.

I wasn’t able to reproduce this problem with Logic 10.7.9 on macOS Monterey. Only tested this with our JUCE plugins.

@mfritze

Configurations:
macOS Tahoe 26.0 and 26.1
Logic Pro 11.1.2 and 11.2.2

1 Like
2

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

3

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?

5

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.

6

We haven’t heard of any such issues and we have over 100,000 installs of our plugins.

7

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.

8

While doing some more tests, I noticed that most of our plugins have an area on the bottom left that does not receive mouse events at all.

This only happens in Logic X with Tahoe.

In Reaper the AU works as expected.

9

Have you tested any of the JUCE example plugins? I’d be interested to know whether those also exhibit the same problem.

Also, are you testing on an Intel or Arm mac?

10

It also happens with the demo plugin. It’s an M1 Arm system.

Logic runs as an Apple Arm process:

image
image1684×128 16.5 KB

Edit: The problem happens very consistent on my system when you move the window fast. For slow movements the window stays responsive most of the time.

Edit: I could also reproduce the dead area problem at the bottom of the plugin:

Plugin scaling is also not smooth. Looks like the UI size is jumping around while resizing:

Tahoe 26.1
Logic 11.2.2
JUCE 8.0.10 and earlier
Apple M1 ARM native ARM

Edit: The user reported that the window “freeze” problem does not happen in intel Rosetta mode and Resizing is much smoother.

11

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.

4 Likes
12

The FabFilter plug-ins don’t use JUCE.

2 Likes
13

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.

14

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