My plugin is very visual and it’s really really important to be able to resize its window, so this is a big deal for me right now. I might have to release my plugin with no support for Logic.
AUv3 resizing is only possible via the window chrome, not via the corner resizer component. The DMG plugins are AUv2.
1 Like
Thanks. That’s good to know, but I’m still confused about a few things:
- What’s “window chrome”? I asked ChatGPT:
Me: “What does the term “window chrome” mean in the context of audio plugin library JUCE?”
ChatGPT4o: "In the context of the JUCE framework, “window chrome” refers to the non-client area of a window, which includes the window’s borders, title bar, minimize/maximize/close buttons, and other elements that are not part of the client area where the main content is rendered. These elements provide the standard operating system window controls and decorations.
For an audio plugin, the window chrome typically encompasses the visual and interactive elements that allow users to move, resize, and control the plugin window itself, as opposed to the content inside the window, which is usually the plugin’s user interface (UI) with controls like sliders, knobs, and buttons specific to the plugin’s functionality.
Managing window chrome can be important for maintaining a consistent look and feel across different platforms and ensuring that the plugin window behaves correctly within the host application."
so by this definition, the “corner resizer component” is window chrome.
-
It sounds that the AUv3 standard sucks harder than the AUv2 standard. Why would that be?
-
My plugin has buttons within it that change the window size and they all work. It’s just the corner resizer control thingy that’s not working. So it’s not an absolute block on resizing in general, just some problem with the control.
-
It’s not clear to me what I should actually do. Should I now set a goal of compiling for AUv2?
Is there some way that I can hack my plugin’s resizing to work with AUv3?
macOS AUv3 is a bit complicated and still has some issues and limitations vs AUv2. It’s better IMO to stick to AUv2 for now which is what most plug-in developers are doing. I don’t have time to answer all your questions i’m afraid, maybe others can chime in.
olilarkin: That’s OK. It’s incredibly helpful to me for you just to say that AUv3 is new and scary and that most developers are on AUv2. I will now focus on figuring out how to get Xcode to build AUv2.
Well that’s interesting. I asked ChatGPT how to generate AUv2 and it said to do it in the Projucer, so I went into my Projucer project and in the “Plugin Formats” setting, it has a bunch of checkboxes for different formats. I currently have “VST3” and “AU” checked. There is also another one called “AUv3” which I had unchecked. I would presume that the “AU” one is AUv2 and the “AUv3” one is “AUv3”. So it would seem that perhaps I’m already generating AUv2. There isn’t a checkbox for AUv2! Hmmmm.
I asked ChatGPT “How can I tell from a .component file whether an AU plugin is AUv2 or AUv3?” and it told me and I went into my plugin’s .component file and opened up the package in the finder and then inspected some files and determined that it’s AUv3! So that’s weird. I’m selecting AU in the projucer and it’s generating AUv3 even though there’s a separate checkbox for AUv3. Hmmm…
.component is AUv2, .appex would be AUv3. In the case of macOS, if I remember correctly, you’ll also need an Application which will need to be loaded in order to install the Application extension (.appex).
It sounds like you’re actually generating an AUv2.
If you build one of the example plugins can you reproduce the same issue?
1 Like
Thanks. I think ChatGPT might have been hallucinating. Here’s what it said about how to tell the difference between AUv2 and AUv3:
I discovered I could use this macOS Terminal command to analyse my AU plugin:
auval -v aufx C:07 CRKT
Part of its report said:
“This AudioUnit is a version 2 implementation.”
so I now think I am generating AUv2.
The resizing problem is still happening though.
The corresponding command for the TrackControl plugin, whose resizing works is:
auval -v aumf TrCt DMGa
I wonder if the aufx vs aumf has anything to do with it.
I went into the Projucer and unticked AU and ticked AUv3 and tried building. The final result was a .appex file instead of a .component file. I put the .appex file in the system components directory, but Logic couldn’t see it.
you need to enable standalone and run the app at least once to register, see here for more.
Anothony, Hi. Thanks for your posting. I have now established that I was always building AUv2. I like the idea of building one of the example plugins. However, when I went to the JUCE examples page at JUCE: Tutorial: Plugin examples it looks as if the plugins do not obviously support resizing. I don’t want to have to download and build them all to find out, and in any case, if I did, and they didn’t resize, I wouldn’t know if it was them or my build environment.
Could you please point me to a plugin project with source code that you definitely know supports plugin corner drag resizing?
Take a look at the AudioPluginDemo, to get to the demo from the Projucer, navigate to File >> Open Example >> Plugins >> AudioPluginDemo. I think looking at the examples and the DMG TrackControl plugin you mentioned you’ll need to call attachResizableCornerComponent() on the editor (if you haven’t already).
1 Like
I just want to say that today I threw everything I had at this problem and spent EIGHT HOURS today (Friday 8 Nov 2024) trying everything I could think of to fix this and utterly failed. This is incredibly frustrating. I managed to create a simple plugin in JUCE that correctly resizes in Logic Pro, but my main plugin still doesn’t resize. I’ve compared them in great detail and I cannot detect any significant difference between them. I’ve disabled size calls. I’ve rearranged the size and resizing calls in the constructor. I’ve inspected every setting in the two project’s Projucer project. Nothing works. This is absolutely nuts and I’m at the point of deciding that I’ll just have to not support Logic Pro when I release my plugin. 
For the record, here’s what the constructor looks like in the simple project where resizing in Logic Pro DOES work:
NewProjectAudioProcessorEditor::NewProjectAudioProcessorEditor (NewProjectAudioProcessor& p)
: AudioProcessorEditor (&p), audioProcessor (p)
{
// Set the size of the Editor window.
int plugin_window_width = 600;
int plugin_window_height = 200;
setSize(plugin_window_width, plugin_window_height);
// Set the Editor window size limits.
int min_width = 200;
int max_width = 1000;
int min_height = 100;
int max_height = 500;
setResizeLimits(min_width,min_height,max_width,max_height);
// Tell the Editor that users are allowed to resize it.
bool allowHostToResize = true;
bool useBottomRightCornerResizer = true;
setResizable(allowHostToResize,useBottomRightCornerResizer);
// This seems like a good idea too.
setOpaque (true);
}
If you are testing in Logic, that is misleading.
Logic shows the resizer cursors on the border, but that only works for apple’s own plugins, not third party ones.
The only way to resize is by using the corner resizer or any other programmatic way to call setSize().
If one day somebody finds a way to leverage the resizer border from logic, they would be in for a huge applause from the audio programmers.
And that is not juce specific, all third party plugins I know of have this problem.
EDIT: we are still talking of AUv2 regardless of the title, right? 
I’m not trying to use the border; I’m trying to use the corner resizer. See the code above. And I’ve succeeded for a HelloWorld+Resizing code plugin! And the one that works does NOT call setSize() except for in the constructor.
My problem right now is that I have a HelloWorld plugin that resizes correctly (using the corner control) in Logic Pro, but I can’t get my much more complicated (30,000 lines C++) plugin to work this way too. I have compared their setsize and resizer code extensively and I just can’t figure out what’s wrong.
Also note that DMG TrackControl resizes in Logic Pro (using a corner control) no problems.
Looking at your code, IIRC you need to call setSize AFTER the setResizable.