NOTE: This only occurs when Logic is run in non-Rosetta mode on M1. Wondering if it is another weird interaction between JUCE and Logic’s new subprocess hosting system in the native version, but the bug is pretty bad…
Repro:
Have a JUCE AU plugin with a GUI that can resize and has a TextEditor element (works with any keyboard-focus sensitive element but most egregious with a component that accepts user text)
Open the JUCE GUI
Enter text into the TextEditor element, see that it works as expected
Resize the gui
Try to enter text in the TextEditor element
Expected:
Text is entered into the text editor element as normal
Actual:
No text is entered and all keystrokes go straight through to Logic. (So if the user tries to delete text, they have likely just deleted their track)
This will cause any issues in products that have their own preset browser with a text editor if they support resizing, so hoping there is some solution on the JUCE side we can do to work around this issue.
One interesting workaround: it seems that for whatever reason, if your plugin GUI has a WebBrowserComponent, you can focus on that and then refocus on whatever the original component was and focus is restored. Otherwise there is no way to get focus in your plugin again without reinstantiating.
I tried Surge and Pianoteq both in LPX 10.7.4 and they exhibit this behavior - after a zoom the keybindings go back to logic instead of the plug. When I tried Surge AU in Reaper it was fine.
So I also tried a non-juice plugin (the plogue dx7) which isn’t a juce plugin and that also showed the same bug.
I think this is a logic bug. If anyone knows folks at apple…
I’ve been a regular Logic user for 20 years. It’s historically my favorite piece of software, in part due to its stability. However, Logic 10.7.x on an M1 is pretty buggy… it’s in the worst shape I’ve ever seen the product, hopefully something the next update will rectify!
Our hesitance in releasing M1 was completely just because of how buggy Logic on M1 has been and how often users come to us first with a bug that is just a Logic hosting bug.
I will say the stability is a lot better now! (but still, unfortunately, not great).
+1 data point for Logic causing issues with keyboard focus in Audio Units version of a plugin I work on. Works fine in other hosts that support AU on M1, also works fine in Logic on Intel machines.
I am an engineer at Native Instruments in the Kontakt team. We ran into this bug as well and submitted a feedback ticket to Apple, found this thread super useful in determining that the issue is Apple side.
Sadly it might not be that simple, because on Apple Silicon AUs are hosted out-of-process and that is all managed by macOS – not Logic/GarageBand/MainStage – it might be very well, that it is a macOS bug. Either way it is pretty probably that it is an “Apple bug”, just which team has to fix it is not clear to me.
Please file bugs via the ProAudio Seed program, so they are seen by us – thanks a lot!
This issue is also causing problems here.
So while we wait for Apple to hopefully fix it, has anyone found a workaround to either recover focus or to resize without losing focus?
Still no fix from Apple it seems. I haven’t been able to find a workaround either.
@mfritze Do you know what the status is on this issue?
@jackwcampbell Can you perhaps elaborate a bit on how you were able to use WebBrowserComponent as a workaround? I have tried various combinations of grabbing focus both before and after resizing to get focus back, but without any luck. Are you simply using grabKeyboardFocus() on the WebBrowserComponent after resize?
