Auv3 resizing issue on macos (not ios)

MacOSX and iOS
41

I’ve been through all that earlier today. In the WORKING CODE above, I setsize BEFORE the setresizeable call and it STILL works, so arguably this is not the problem. But just to be sure, I swapped these two calls in my complex plugin that doesn’t work — and it didn’t work. But thanks for the idea.

42

I think I’m either going to have to abandon Logic Pro, or work up from my tiny working program to the complex plugin by adding code piece by piece until it stops working. That might take a week or more!

43

I wouldn’t care so much about this issue except that my plugin is very graphical and being able to resize the window is incredibly important, and it works in all the other DAWs.

44

Sorry for the detour, maybe my knowledge was outdated.

Good luck

1 Like
45

At least I have a tiny plugin for which resizing on Logic Pro works. That’s better than where I was six months ago. So in theory I should be able to figure this out. It’s just that I’ve spent eight hours trying to figure out why my large plugin doesn’t work in this way and it’s driving me nuts.

46

Rather than trying to make your large plugin work you might want to take your simple plugin and try to break it. Gradually add to it until you hit a breaking point. What happens for example if you take your simple plugin and add the audio editor component from your large plugin as a child of the simple plugin? does that work? At this point too you might want to consider things that you would never expect. For example make sure every setting is CMake/Projucer is the same between them. Otherwise I’m not sure what to suggest. Once you have something that breaks even if you’re not sure why, hopefully it will be easier to share or at least guide you into an area to look into further.

Best of luck.

1 Like
47

I took my complex plugin and put in “if (SIMPLE_EDITOR) return” on all the public methods of the Editor object. So I brought my complex plugin’s Editor to the same state as my simple test plugin. It resized. Then I started deleting these ifs in each of the public methods and stuffed around a bit.

In the end, I got my complex plugin working completely with window resizing working and tracked the problem down to a single call:

setResizeLimits(min_width,min_height,max_width,max_height);

Not so surprising huh? However, the CRAZY THING is that the arguments to this call which I traced were not something like:

setResizeLimits(1000,500,1000,500);

which would have made total sense (constraining the window to a single size) but rather:

setResizeLimits(275,235,5200,2050);

In other words, constraining the width to [275,5200] and the height to [235,2050]. These are generous loose constraints and should not have suddenly locked the window so that it could not be resized.

FURTHERMORE, immediately after the call, I traced the value of
isResizable()
and it was always true. So it wasn’t that calling setResizeLimits() was also making it non-resizable and you have to set back to that. It’s resizeable and the constraints are loose. So why is this locking the window down to one size?!!

So this is crazyland.

48

Because I’m in crazyland now, I tried putting this after each call to setResizeLimits() in case isResizeable() was lying to me when it returns true.

bool allowHostToResize = true;
bool useBottomRightCornerResizer = true; // Note: I tried false, but that didn't make resizing work.
setResizable(allowHostToResize,useBottomRightCornerResizer);

So I’m recording that this DIDN’T work. The call to setResizeLimits still caused the window to be locked to its current size.

49

I want to say that, while I was deeply suspicious of the setResizeLimits() call earlier when I was diagnosing this problem, I was thrown off the scent by the fact that I was tracing its arguments in the tracelog and they always looked really sensible (as above) so I thought the call would be benign. It’s only when I deep dived and started commenting out and commenting in code that, after another 2.5 hours, I managed to narrow it down to that single call. There was no rational reason to suspect that call based on the parameters I was passing to it. That’s why it took so long to identify it as the culprit.

I have now completely fixed this problem by doing the following:

  1. Not calling setResizeLimit() if the host is Logic Pro. You can test this with:
    juce::PluginHostType plugin_host;
    if (!plugin_host.isLogic()) { … }

  2. In the Editor object’s resized() method, I inspect the new window size, and if it is too small or too large, I fix it on the spot like this:
    // Get the new size of the window.
    int current_actual_window_width = getWidth();
    int current_actual_window_height = getHeight();

    // Set the official window size variables with the current actual size.
    // Do not accept the current actual window size if it exceeds our limits!
    plugin_window_width = current_actual_window_width;
    plugin_window_height = current_actual_window_height;
    plugin_window_width = int_min(plugin_window_width,plugin_window_width_max);
    plugin_window_width = int_max(plugin_window_width,plugin_window_width_min);
    plugin_window_height = int_min(plugin_window_height,plugin_window_height_max);
    plugin_window_height = int_max(plugin_window_height,plugin_window_height_min);

    // If we had to constrain the window size, adjust the size of the real window
    // to match the official window size.
    if ((current_actual_window_width != plugin_window_width) ||
    (current_actual_window_height != plugin_window_height))
    {
    setSize(plugin_window_width, plugin_window_height);
    }

The latter code should never be invoked on non-Logic DAWs as the window size constraint set by calling setResizeLimit() should mean that an out-of-bounds window size will never be delivered to the code above in resized().

THIS HAS COMPLETELY SOLVED THE PROBLEM AND I RECOMMEND THIS SOLUTION TO ANYONE ELSE FACING THIS PROBLEM (the problem of your plugin’s window not being resizeable in Logic Pro).