VST3 resizing issue in Reaper

When we specify a “FixedAspectRatio”, the window is not correctly resized (its ratio is not constrained) and there are some glitches.
this can be reproduced with the JuceDemoPluginAudio with the following added at the end of the JuceDemoPluginAudioProcessorEditor constructor :

if (auto* compBoundsConstrainer = getConstrainer())
    compBoundsConstrainer->setFixedAspectRatio (1.5f);

(it’s working fine with VST2)

edit: I only tested on mac, not on windows


I am also experienced VST3 resizing weirdness in Reaper (64bit, OS X).

In my case I have observed that if either setResizable or setResizeLimits is present in the editor’s constructor, then the width and height defined in setSize are ignored, and the plugin GUI is initially scaled to fill Reaper’s FX window.

Additionally, if setFixedAspectRatio is also present then resizing Reaper’s FX window by dragging its edges will cause the plugin GUI to be resized, which is not the case with VST2 plugins (I believe the plugin should only resize when Juce’s resizable corner component is dragged). The GUI will “jump” around the screen as the FX window is resized, and might even be positioned off screen.

I have observed this behaviour in VST3 versions of commercial Juce plugins by other developers.

Here is example code that will reproduce the problem:

    setResizable(true, true);
    setResizeLimits(600, 400, 1200, 800);
    setSize (600, 400);

This commit should sort things out - can you see if it fixes the issue for you?


Thank Ed! That commit has stopped the plugin glitching while dragging, for me.

The inital size of the plugin is still incorrect, though. On initial load my VST3 plugin’s GUI fills the entire width of Reaper’s FX window, ignoring the size defined in setSize()

I’ve added the following lines to a default audio plug-in project generated by the Projcuer:

setResizable (true, true);
setResizeLimits (600, 400, 1200, 800);
getConstrainer()->setFixedAspectRatio (1.5);

setSize (600, 400);

but I can’t reproduce the problem - the size of the plug-in window is 600x400 when opening. Is there something else I need to add?

thanks Ed, seems to work fine for me.
I see that the behaviour is a bit different between vst2 and vst3.
I see what jnicol means. with the vst3, the plugin will automatically scale to fill reaper’s window (click on the ‘+’ in the topbar of the window to test that), while with vst2, the window’s size was not impacting the plugin size.
I think I actually prefer the vst3 behaviour.

Hi Ed. I’ve made a video which illustrates what happens when I build a default audio plugin-in with the same code, and add it to Reaper:

If I add the plugin to a new Reaper track (“Insert virtual instrument on new track”) it is the correct size. But if I resize the FX window then the plugin scales up until it reaches the upper limit set with setResizeLimits. Then, if I add a new copy of the plugin to that larger FX window, it is rendered at its maximum size, instead of the size defined in setSize.

What I would expect to happen is that the plugin is always rendered at its default size initially, regardless of the size of the FX window it is added to, and only scales up/down if the user drags its corner resizer (like VST2 plugins).

Hopefully my video helps to illustrate the issue :slight_smile:

That’s odd, I’m not seeing that behaviour - if I do the same and add a new plug-in instance after scaling it to max then it resizes to the correct size when opening. I’m on macOS 10.14.2 and the latest Reaper v5.965.

I’m using the latest Reaper (tested in 32 and 64 bit versions), but I am still rocking OS X 10.12.6, so perhaps that’s the problem.

I will assume that the issue I described is isolated to me, but if I see it crop up on another system I’ll let you know.

Thanks again for fixing the other issue with the plugin positioning!

I have some glitches & resizing ‘bumps’ in Cubase (9.5 on mac) with the VST3 with latest dev tip (can be reproduced the same way as above).

I’m using the latest reaper / OSX and was able to reproduce the issue with the VST3 version of the plugin. The plugin automatically scales to reapers plugin window size.
A user reported the same issue on cubase where it opens the resizable plugin always with the same size and ignores setSize() (i didn’t try it myself on cubase so far, so i’m not sure).

Reproduction steps:

  • New Projucer Plugin Project
  • Adding the lines you mentioned above.
  • Add the plugin to a channel
    –> the plugin scales to reapers plugin window size

or you could also resize the plugin size, selecting another plugin. Select the plugin again and it is scaled to the plugin window again.

At a first sight it looks like a good thing that it scales to fit the window, but i don’t like that the behaviour is not the same as for the VST2 and AU.
And a smaller plugin with 3 knobs for example almost scales up to full screen, depending on reapers window size.

It works if i’m not using the resizer infrastructur of the audio editor and create my own resizer:

this->resizer.reset(new ResizableCornerComponent(this, &componentBoundsConstrainer));
this->setSize(600, 400);
this->componentBoundsConstrainer.setSizeLimits (600, 400, 1200, 800);

As soon as i add the constrainer to the AudioEditor, the plugin scales to fit the window:


Is this expected?

I know it’s required to set the container on iOS AUv3 where you want that the host scales the plugin to the iPad or iPhone size. Is this something the host requests?

Hi @kunz. The issue you’ve described (VST3 filling Reaper’s window, ignoring setSize), is the same issue I am observing. It’s the last thing I’m hoping to fix before starting beta testing on a plugin.

I have noticed that if setSize is called later (in my plugin the user can click a “reset GUI scale” button), then the size is correctly set. So it’s not that setSize doesn’t work, but the DAW seems to ignore (or override) the first call to setSize in the editor’s constructor.

The only workaround I have found so far is to user a Timer callback to set the plugin to its correct size after the DAW has rendered it. The timer can have a 0ms duration and it will work, but there is still a brief flicker as as the plugin resizes. Obviously this is a horribly ugly solution - were you able to come up with anything cleaner?

I have been able to resolve this to my satisfaction.

In my editor constructor:

setSize(600, 400);

In my timer callback:

setResizable(true, true);
setResizeLimits(600, 400, 1200, 800);

So basically I initially set a fixed size for my plugin, then after a brief time make the component resizable.

The use of a timer seems to be necessary. It is not sufficient to call setSize before setResizable in the constructor.

This approach fixed VST3 resizing issues for me in both Reaper and Live (macOS). I haven’t tested elsewhere yet.


Just ran in to a similar problem, and I think I found an easier fix than @jnicol. He’ll have to check to be sure, though. The order of operations (this assumes you use smart pointers for everything, like our lord and savior Jules recommends):

  1. Reset your resizer and add/make visible.
  2. setSize()
  3. Set your constrainer’s variables (resize limits, fixed aspect ratio)
  4. this->setConstrainer(&yourConstrainer)

Do all this at the very end of the editor’s constructor, in that order, and it should get around the problem. Effectively, setSize() calls resize, then you assign the constrainer. Basically the same as jnicol’s method, except no timer necessary.

1 Like

This works when you are using your own constrainer and resizer. It does not work if you are using the given JUCE implementation:

setResizable(true, true);

Only the VST3 format is affected. So i think something in the JUCE code does not work as expected in reaper and maybe other hosts with scalable plugins.

Not sure if i should change it back to use my own constrainer and resizer. Sounds not right to me somehow because we already have a constrainer we can get.

@ed95 Here is a video that describes the VST3 plugin size problem. The plugin always scales up and fills the window. This does not happen with the VST2 version.

https://tal-software.com/downloads/Screen Recording 2021-02-13 at 09.27.22.mov

This works if i implement the resizing manually without setResizable(true, true); or with the timer solution. In this case the VST3 host probably don’t know that the plugin is resizable and it does not scale up.

The work around with the timer and maybe also the implementation without setResizable(true, true); does not work anymore on linux in Bitwig. In this case the host does not scale the window anymore when scaling the plugin.

See here:

Right, I’m just not seeing that behaviour (macOS 10.15.7 and Reaper v6.23). Here is a screen recording of me doing the same thing, using a fresh Projucer plug-in template with only these lines added in its constructor:

setResizable (true, true);
getConstrainer()->setFixedAspectRatio (1.5);
setSize (300, 200);

Is it possible that you are doing something else in your plug-in which could be affecting this? Can you try with just the default template as I have done?

Thanks again for looking at this. After endless try and error i finally found the problem. It’s a reaper property that controls that behavior:


Automatic resize FX window was not enabled for up and down in my case :grimacing:

So it looks we can remove the work around from above.