Juce demoplugin does not resize in OSX + VST3 in Cubase 8; Cubase Pro 8.5


#1

Configuration:

  • OSX El Capitan 10.11.4
  • Xcode 7
  • 10.11 SDK
  • Cubase Artist 8 and Cubase Pro 8.5
  • Release build

The Demo plugin does not resize in Cubase Pro and Cubase 8 when using the VST3 version. It does work properly though if the VST2 plugin is used.

The AU version does also resize properly.

I get similar issues in other plugins but the demo plugin is probably a good start to look at. Any ideas how to resolve this?


#2

Update: Loading the demo plugin Audio Unit in Apple’s AU lab and dragging the resizer around also gives problematic results…

The resizer itself disappears, all controls above the piano key component disappear or get scaled erroneously…

Picture below shows the demo plugin after a few resizing operations:


#3

I can confirm the resized() doesn’t get called with JUCE 4.1 (Mac SDK 10.9), OSX 10.11.4 and Cubase 7 (64bit), while resizing in other situations (AAX, AU) works.

Another thing is that Logic offers scaling (i.e. 50%, 100%, 200%). But this is disabled with my JUCE based plugin. How can the plugin tell the host that it supports scaling?


#4

Can somebody please confirm, thats either a

  • user error,
  • my programming error,
  • a cubase error, or
  • that you just don’t care and I can stop bothering.

thanks,
raketa


#5

I’ll have a look at this tomorrow. However, I believe the AULab bug is a different bug. This occurs if you resize the audio plug-in to a size that is smaller than the minimum size of the host window. I’ll also have a look at this.


#6

OK this fix was a bit more involved than I expected. VST3 wants to know the size constraints of plug-ins but JUCE had no way to probe what these constraints are as every editor could handle this differently internally.

We’ve now added a functionality to add size constraints to editors which will be respected by the various plug-in formats. By default, editors will be non-resizable and constrained to a fixed size which you can set with setSize or setBounds. If your editor is resizable, then you can now call setResizable (true) or setResizeLimits (minWidth, minHeight, maxWidth, maxHeight) in your constructor. Both will also create the resize box for you. See, for example, the updated JuceDemoPlugin.


#7

Thanks fabian,

that sounds great!
I am assuming this is at the JUCE 4.2 tip. So before being able to profit from that I will have to update to 4.2, which is a bit of a hassle due to the JUCE MACRO orgy.

Thanks,
raketa.


#8

JUCE MACRO orgy will be fixed soon… :wink:


#9

Thanks for looking into this Fabian!


#10

This should be optional, plugins may user other technics for resizing (for example re-scaling the interface with fixed ratios)


#11

That’s fine. You can still set a custom constrainer.


#12

Sorry i don’t understand. In the source code it looks like there is a ResizableCornerComponent now automatically added to the plugin-component. I don’t want that, i have my own type of resizing mechanism


#13

@fabian : Suggestion it would be cool if setResizable() has an option not to add the ResizableCornerComponent


#14

After some investigation i think there are some bugs.

If i set the custom constrainer via setConstrainer(),

it will check if there is the resizableCorner is used. (Which is not, because i don’t use it that way)
This results in a call to setResizable(false)

Which will again will use the defaultConstrainer as constrainer :confused:

I think the existence of resizableCorner shouldn’t be the indicator if a plugin can be resized.

A simple virtual bool checkSizeConstraint(w,h) callback in the AudioProcessorEditor would be much easier, than the current mechanism.


#15

Would be cool if someone fix this behavior, currently its not possible to use a custom constrainer


#16

Anyone anyone?


#18

OK this should be fixed on the latest tip. You can now specify if you want to use the resize corner or not.


#19

I have some questions: I have a plug-in made with JUCE 4 before these changes.

It is resizable in the sense that I have manually added to it a custom corner resizer.

As per original problem description, this worked as expected in all OS+host+format combinations, except for VST3 in Cubase on Mac. In that case, dragging the custom corner resizer didn’t have any effect.

Now, I have updated the project to use the newly released JUCE 4.2.3, where these changes have been integrated, and I have found that just by doing that I get the corner resizer to work as expected also for VST3 in Cubase on Mac.

This puzzled me a little because I haven’t added a setResizable (true) statement to my editor yet, hence I would have expected my custom corner resizer not to be working yet (because the doc says that by default an editor is considered to be not resizable), but it turns out that it works as I expected just out of the box.

More puzzling is the fact that if I add

setResizable (true, false) 

to the constructor of my editor (the second argument says that I don’t want a corner resizer, because I already have my custom one in place), what I get is that my custom corner resizer again stops working. But in this case I get the “resize” mouse cursors (left-right and top-down arrows) when I hover the borders of the window of my plug-in, which I didn’t get without the setResizable() call above.
However, neither trying to resize using the borders of the window does work (but could that be because I haven’t explicitly set any size constraint?)

The doc for these newly added methods is not very detailed, but could it be that, at the current state of code, you should use setResizable() only if you want your plug-in to be resizable using the host provided facilities (i.e. window borders), whereas if you only wish to resize your editor using “internally provided methods” (for example a custom corner resizer), you can just leave it set to false?

And this springs another question: if I have a plug-in that can open/close a “drawer” with the press of a button, or whose GUI has a “normal” and a “mini” mode, this means that only two sizes of the plug-in are admissible, not all those in between, and they are switched with controls internal to the GUI.
Should this plug-in be declared resizable or not?

Disclaimer: my tests have so far been done with Cubase 7.5 because Steinberg isn’t very responsive at handling NFR requests…


#20

OK I’ve added more detailed documentation to the setResizable method.