AUv3 resizing issue on develop

MacOSX and iOS
1

Hi

I am finding on develop (and 7.0.5) that AUv3 plugins in Logic for macOS do not resize as I anticipate when calling setSize, and in Live & Reaper they do not resize at all. I would expect a call to setSize in the audio processor editor to behave as it does in VST3 and simply resize the plugin window.

I’m also finding that resizing in Logic when dragging the side of the window only provides fixed aspect ratio resizing (I would expect it to only get wider not taller when dragging the side), and resizing from the bottom corner also only allows a fixed ratio resize (I would expect any height and width to be possible).

I have prepared a video to illustrate the problem here.

In Live/Reaper, I can’t change the window size manually or via setSize so the content inside gets cropped if it’s too wide etc.

As a side note it would be good to know whether it is possible with Logic Pro hosting AUv3s that the window size can be fixed (i.e. the user is not provided with a freely resizable window and the plugin controls the size as is more usually the case).

Thanks
Matt

2

If it’s anything like AUv3 on iOS, the plugin effectively has no control over its own size. On iOS you get given a window to draw and no matter the size/aspect ratio, you have to do your best with it.

3

To echo what was already said, AUv3 doesn’t resize in the same way as other plugin formats. The host has full control over the editor size. The plugin gets a chance to declare supported sizes on startup, but hosts may ignore these suggestions. For example, Logic seems to pick one of the supported sizes, but will still allow aspect-ratio-preserving resizes after that.

4

So then is it the case that even in hosts such as Reaper and Live that support AUv3 we don’t have a way to ask the host to change the window size at all? Supposing it needs to double in height or width to reveal a browser that is usually hidden, we would be stuck with the same size window and expect the user to resize it to either reveal the new content being drawn in a hidden region or react by manually resizing a window because everything has been shrunken down to accommodate the extra content?

To summarise, at an underlying AUv3 format level, setSize is simply not able to request a window resize because we have no influence over that during runtime. Is that correct?

Regarding Logic, how do we declare the supported sizes? Sorry I have missed this facility and would like to try using it.

Thanks.

5

Yes, that’s right.

Apologies, I’d misremembered. The mechanism I was thinking of was the supportedViewConfigurations: function. The way this works is that the host will pass a list of editor sizes that it would like to use, and the editor can return whether or not it supports each of those sizes. The JUCE implementation uses the editor’s bounds constrainer to determine whether each suggested size is supported.

6

Thanks for the info about that, I’ve added a bounds constrainer member to this little test editor I am experimenting on and configured it as follows:

constrainer.setMinimumSize(600, 300);
constrainer.setMaximumSize(800, 450);
setConstrainer(&constrainer);
setSize (700, 375);

In Reaper it doesn’t do much ‘constraining’, in Live I can’t resize AUv3 windows anyway (a host limitation I assume), and in Logic purely adding this causes the window to iteratively grow or shrink each time I closed and re-opened the editor (I didn’t figure out what the logic was on whether it was going to be in a growing or shinking mood) and the dimensions didn’t stay within the constraint bounds anyway (but it did get me the initial aspect ratio I wanted so that’s a plus).

7

I will note, for people that are searching this down the road, that the above information is only correct for iOS AUv3. If you’re searching this for desktop, reuk’s reply is entirely incorrect. Resizing and setSize work fine in desktop AUv3. Just constrain your bounds and set an aspect ratio.

8

I disagree. If I open the AudioPluginDemo AUv3 in Logic, then the bounds constraints set by the constrainer are ignored. The initial aspect ratio and size is correct, but resizing the window after that always maintains the aspect ratio, although free resizing should be possible. It’s also possible to resize the window to smaller than the minimum size set in the constrainer.

If I call setSize() in a timer callback, then the editor’s view does resize, but the host isn’t aware of the change, so the size of the window containing the editor doesn’t change. As a result, parts of the editor might be hidden in one dimension, while the containing window might be too large in the other dimension. Finally, if I now begin a host-initiated resize, the view snaps back to the initial aspect ratio.

out

As described above, the min/max bounds set in the constrainer are ignored by Logic. Logic does maintain the plugin aspect ratio, but this isn’t helpful if the aspect ratio needs to change after the editor has become visible.

9

First of all, let’s stipulate that how it is done in AudioPluginDemo and how it is done in a shipping multi-platform commercial product are worlds apart, so it is (apologies to all the hard working folks at JUCE) not a great example.

Here is our Enso, rendered as an AUv3.

Min and max sizes and aspect ratio are respected fine; works just like it does in all other formats.

2 Likes
10

@crandall1 please correct me if I’m missing something but I think the problem being described here is in cases where a user doesn’t always want a fixed aspect ratio, or they would like to call setSize to specify a specific size / aspect ratio, rather than relying on the host to specify the size / aspect ratio. The example you’ve kindly provided appears to show

  1. A plugin that is only resizing with a preserved aspect ratio.
  2. Resizing a plugin using the host resize handle. I assume the plugin isn’t calling setSize and the host then responding to that, instead I suspect the host is setting the size and the plugin is responding to the new size.

@reuk said (emphasis mine)

Logic seems to pick one of the supported sizes, but will still allow aspect-ratio-preserving resizes after that.

I think this perfectly describes what you’ve demonstrated in the video you shared?

It may well be that it is just generally good/best practice to only allow the host to resize the plugin, or to stick to a specific aspect ratio, but there are certainly other use cases to consider and it may be a surprise to users given some other hosts / plugin formats are more flexible.

11

@anthony-nicholls yes those were my concerns. Some plugins have a requirement to be able to adjust an aspect ratio in response to certain workflow requirements initiated from a plugin UI event (i.e. clicking something inside the plugin to switch a view mode). That might be wanting to hide/reveal some advanced controls that are only occasionally needed or only of interest to a subset of users, or briefly wanting to use a large/expanded integrated file or presets browser, or other advanced facilities that would typically not be required for general usage that just clutter the UI unless needed.

It seems the only option if we cannot adjust an aspect ratio to a new fixed ratio is to essentially have plugins in ‘full view’ mode at all times just in case the advanced features are ever needed, or maybe add internal scroll-bars, or worst embark upon fundamental redesigns to accommodate this aspect of the AUv3 format. I am surprised if this is a requirement for adoption of AUv3 as it is such a commonly supported usage model in other formats.

The example given looks like these are not a concern because the interaction shown does not change the aspect ratio, and resizing the plugin from the outer plugin container window is a perfectly acceptable model for this kind of a design.

My other concerns were the resizing issue in Logic when opening and closing a window which feels like a bug somewhere, I have illustrated those here. It seems to be growing the window on each close/reopen after it has been expanded a little, and vice versa.

1 Like