Auv3 resizing issue on macos (not ios)

the demo auv3 plugin doesn’t resize correctly in logic and garageband. i believe this is a juce bug - apple’s sample auv3 does not have this problem. see this video for an example of both side-by-side in logic.

i found mention of this in a thread on another forum and the suggestion there was that this code is responsible for the (working) resizing in the apple demo code:

    func pinToSuperviewEdges() {
        guard let superview = superview else { return }
        translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            topAnchor.constraint(equalTo: superview.topAnchor),
            leadingAnchor.constraint(equalTo: superview.leadingAnchor),
            bottomAnchor.constraint(equalTo: superview.bottomAnchor),
            trailingAnchor.constraint(equalTo: superview.trailingAnchor)
        ])
    }

i’m currently trying to integrate this into the juce auv3 wrapper but i’m wondering if anyone else has figured this out on their own or if the juce folks are aware/working on a solution as well?

1 Like

I just encounter the same issue. Resizing the window from both plug-in and from host causes weird look. And host crashes at last. This is critical.

I have a similar problem with AUv3.

If I have a resizer at bottom right of the screen, the Host window doesn’t resize to match my internally resized component. This is also seen in the Juce Audio Plugin Host app.

If I resize the host window in (say) Logic, my internal component isn’t resized to match

Pete

FWIW, I’ve just tried with tip of develop d4e802016 (11/03/2021), and the internal resize dragger doesn’t resize the container Window for AUv3 in Audio Plugin Host or Logic Pro.

HTH!

Pete

I’ve tested this with the demo project on Catalina 10.15.7 with Logic 10.6.1.

When “AUv3 Mode” is enabled in the plugin manager, resizing does not work for the demo project:

trimmed

However, disabling AUv3 mode (so that the plugin runs in-process) does allow resizing to work as expected in the demo.

At the moment, I think this is likely to be a bug with Logic’s handling of plugins hosted out-of-process. Is anyone aware of an AUv3 plugin which resizes successfully in Logic when running out-of-process (i.e. with AUv3 Mode enabled), which would disprove this theory?

i just verified i get the correct behavior from the AUv3FilterDemo plugin with auv3 mode checked on osx 11.2.3 with logic 10.6.1:

Interesting, thanks. I’ll see whether I can reproduce this behaviour on Big Sur rather than Catalina.

@reuk just to note, I’ve tried Wotja AUv3 again using the very latest tip of develop, and it isn’t resizing the container window, even in the Juce Audio Plugin Host. This is on Big Sur.

If anybody wants me to try something out on either Big Sur or Catalina, please ask!

Pete

For me, flipping the AUv3 checkbox makes no difference.

Altering juce_AudioUnitPluginFormat.mm, to change the use of kAudioComponentInstantiation_LoadOutOfProcess to kAudioComponentInstantiation_LoadInProcess, makes zero difference either :slight_smile:

Pete

I’ve spent some time debugging this. There seem to be several issues with AUv3 resizing, only one of which we can work around in JUCE:

  • JUCE plugins were not responding to host-initiated resize requests. I have a fix for this, which I’ll push once it’s been reviewed. Unfortunately, this only seems to work on Big Sur. On Catalina, I can’t get host-initiated resize to work for JUCE plugins or for Apple’s AUv3 Filter Demo. Given that Apple’s demo is broken, I think this is likely a platform issue.
  • Client-initiated resize (e.g. from a corner resizer or dropdown inside the plugin) doesn’t work for JUCE AUv3 plugins. So far, I haven’t been able to find any AUv3 plugin that can be resized from within the plugin itself. I also haven’t been able to find any documentation that would suggest client-initiated resize is possible. If you know of a plugin where this works, please let me know. At the moment, I think this may not be supported by the plugin format.
  • Logic’s handling of AUv3 resizing seems to be a bit broken:
    • If the AUv3 reports that it doesn’t support any of the view configurations that Logic requests, the plugin window will initially be sized to the view controller’s preferredContentSize. If the view is then resized, closed, and reopened, the editor will not reopen at its previous size. Repeatedly closing and opening the window will cause the editor to grow/shrink exponentially. I can reproduce this issue in the AUv3 demo, if I modify it to support none of the requested view configurations. This appears to be a Logic bug.
    • If the AUv3 reports that it does support one or more of the requested view configurations, Logic will pick one of those view configurations rather than using the preferredContentSize provided by the view controller. As a result, the view may not respect the aspect ratio set in the plugin editor’s constrainer. This does prevent the issue with the editor growing/shrinking on open, though. Again, this behaviour is consistent with the AUv3 demo.

The least-broken setup at the moment seems to be:

  • Avoid allowing the user to resize the plugin view from within the editor. Disable corner resizers etc. if running as an AUv3. Rely on the host to provide resizing capabilities.
  • Attempt to support at least one of the view configurations that Logic requests, in order to avoid the exponential-resize bug. Logic 10.6.1 requests 1024x768 and 1366x1024.

Hopefully that helps.

This patch fixes host-initiated resize for AUv3 plugins on macOS:

2 Likes

Hi @reuk thanks so much for investigating this. What a pain, eh?!

I’ll check-out your changes tomorrow. Best wishes,

Pete

1 Like

@reuk it works for me now, thanks!

1 Like

@reuk that works very well - thanks a lot!

Have you considered making the plugin host window resizable directly in macOS (in the Juce Audio Plugin Host app?)

Best wishes,

Pete

Resizing plugin views was added in this commit:

1 Like

Hi @reuk - thanks for the info! :slight_smile:

Pete