I’ll add to the feedback given here : the bug is not tied to Logic in particular. It happens on M1 computers with the latest universal builds of DAWs (running M1-native) which host AU plugins in a different thread. Here’s the behaviors I noticed that leads to this statement :
In Logic Pro 10.7.3, opening either a M1-Ready plugin or a x86_64 one opens it in another thread (AUHostingService and AUHostingCompatibilityService respectively) and the bug happens in either cases.
In Ableton Live 11.1, opening an M1-Ready AU doesn’t start another thread and the bug is not reproductible. With x86_64 However, it runs it through the AUHostingCompatibilityService and hence the bug happens.
In Reaper, opening a VST3 which is either M1-Ready or bridged don’t fire the bug (hence it’s really tied to the AU thread since Reaper is opening x86_64 plugins in a distinct thread as well). Opening a native M1 AU works well too, but as expected opening a x86_64 will trigger the bug as it runs through the AUHostingCompatibilityService
Running these DAWs under Rosetta runs the old legacy AUHosting single-threaded process and don’t create any issue.
It seems to be related to this issue : Auv3 resizing issue on macos (not ios) - #15 by peteatjuce
Although I have no idea how to ensure Logic is bridging my plugin to AUv3, the fact the M1-Native plugin runs out of process as well seems to indicate there’s some kind of bridging technology here that Ableton and Reaper don’t do. Furthermore I’ve got the same resizing problem than the one @reuk had at the time of this dev.
I managed to compile my plugin in AUv3 today and I can confirm it has not fixed the problem. With AUv3 the plugin-initiated-resizes don’t do anything whereas in AUv2 the Editor is resized first and then the window is resized after it after a short delay. Hence the behavior seems to have gone toward AUv3 but has not regressed to the point it prevents client resizing. But it seems that the AUv2 plugins are not bridged to AUv3 after all or at least it’s not the issue.
I noticed many other M1 native plugins have the same behavior on Logic Pro hence I guess it’s simply a Logic bug. I could deal with it but I can’t ignore the setAlwaysOnTop infortunately…
For AUv3 plugins, it’s a bad idea to create additional desktop windows. In Logic, transparent desktop windows will be given a magenta background as a security feature - this often looks out-of-place, especially for windows with rounded corners, because the corners get filled-in in magenta (relevant post here). If there’s any way of modifying your design to use a single window, I’d recommend doing that.
In terms of resizing, AUv2 plugins only support client-initiated resize (e.g. using a corner resizer) in Logic, but AUv3 plugins only support host-initiated resize (using the plugin window’s border). You could consider querying the AudioProcessor::wrapperType in your plugin, and using the result to decide whether or not to display a corner resizer.
Actually I’m not interested in publishing an AUv3 version of my plugin in particular. I thought it would help to resolve the bugs that occurs on M1-native DAWs (and more specifically Logic) but it turns out it does not.
The additional desktop windows are buggy on native-M1 Logic with AUv2 as well, and that’s the main problem I’m facing (the resize behavior is strange but is shared between other companies plugins so I’ll deal with it).