VST3 plugin editor resizing glitch/issues

[haroldgroenenboom]

Hey JUCE,

I’ve encountered some scaling issues with a resizable plugineditor on Windows 10, with VST3 in FL Studio 20, Bitwig and Ableton 10. (using the setResizable() method with all argument combinations). I’ve encoutered this issue in product code. The same issues come up with an empty JUCE plugin with only the setResizable() method added.

Some specs:

Windows 10 Home 64bit 19042.746
Plugin format: VST3 64bit Release
JUCE version: 6.0.7

FL Studio version: producer edition v20.8 (build 2115) (64bit)
Ableton Live 10 Suite (10.1) build: 2019-05-14_820f098a4a

something about FL and resizing

During the testing of product code with VST3 I’ve found out that FL Studio shows 2 resizable corners. One from JUCE from the plugin itself and one from FL Studio. FL Studio only shows this resizable corner, when a resizable plugin is loaded. Otherwise no resizing tooltips are shown.

FL Studio glitches

This often happens when I reduce the size of the plugin window using the FL studio corner tooltip. There is always bottomright piece of the editor left black. When this happens resized() or paint(Graphics&) are not called.

This always happens when I resize with very small plugin sizes using the JUCE resizable corner. This one is not really interesting for the product code, as the window size is extremely small, but I figured it might be helpfull to add as well. When this happens the juce::Component bounds are wrong 100w, 50h instead of the actual 150w, 50h, so I guess that’s why the painting is warped

Ableton glitches

I’ve only encountered Ableton glitches once, using the same build, which is weird. But I will update if I encounter the same glitches again.

When enlarging the plugin using the JUCE resizable corner

When shrinking the plugin window using the JUCE resizable corner

What works

Unmentioned interactions in FL or Ableton work great.
Resizing further works great in:

• Cycling Max8
• JUCE AudioPluginHost
• Traction Waveform

In general release builds seem to do a lot better and seem have less chance of glitching

Any ideas on how to fix this?

[jakemumu]

This has been killing me as well.

[scopedaudio]

Tagging @ed95 . Sorry to bother you again but we experience the same issue. Would you mind looking into this?

Thanks,
Milan

[haroldgroenenboom]

I’ve found out more specifics about the glitches/buggy behavior in Ableton, and it mostly has to do with resizing being possible from all corners, we seems to be similar to the issue in FL Studio:

Here is a short GIF to show what’s happening:

[haroldgroenenboom]

Hey all, I’ve found out a bit more details about this issue and it strangely seems to be JUCE 6 related.

We haven’t had issues with v5.7.4 and after consulting with someone, we’ve heard they didn’t encounter these issues with 5.7.4 either.

So I’ve tried two things:

Use v5.7.4 in an empty JUCE plugin project

Perfect results! All scaling/resizing issues in Ableton and FL are gone (still Windows VST3)

Use v6.0.7 with some modules from 5.7.4 in an empty JUCE plugin project

Perfect results as well! Again all scaling/resizing issues in Ableton and FL are gone (still Windows VST3)

These are the changes I’ve made to the 6.0.7 version:

Conclusion

This issue seems to be JUCE6 related, I would love to get some feedback on this and to hear if other people have encountered this as well with the newest JUCE version?

[jakemumu]

Can confirm this also started for me when changing to JUCE 6

[kunz]

I can also confirm. Same happens on linux with resizable VST3 plugins:

Linux VST3: Resize / host window does not change the size

The hosts plugin window does not change the size, when resizing VST3 plugins in Bitwig on Linux. Closing and reopen the plugin UI opens the window with the right size. Latest JUCE 6 develop branch.

Looks like the host gets no notification when the window size changes.

[mboerum]

Yeah – we’ve also had the same problem but on AAX for Mac as well. Any help here would be very much appreciated.

[mboerum]

agreed. we can reproduce the same issues. Would be great if we could please get a fix!

[haroldgroenenboom]

Hey everyone,

I’ve been looking into the diff between 5.4.7 and 6.0.7 and I might have found something!
In the juce_VST3_Wrapper.cpp r1567 I’ve found the following code inside the pluginwrappers resized() method:

#if JUCE_WINDOWS && JUCE_WIN_PER_MONITOR_DPI_AWARE
    if (! lastBounds.isEmpty() && isWithin (newBounds.toDouble().getAspectRatio(), lastBounds.toDouble().getAspectRatio(), 0.1))
        return;
#endif

This seems like an optimization of sorts? When attaching the VST3 to the debugger I’ve found this return statement is hit whenever the glitching occurs. I think the resized() call then stops propogating to the child components, which is why no repainting happens.

So I’ve tried simply commenting this out, and no more glitches in Ableton and FL Studio! With product code and with an empty project as well.

Can you confirm this JUCE? If this works maybe this is something you could commit on the develop branch, so we can work from that?

[scopedaudio]

That seems to do the trick!
@jules or someone from the Juce team, can you please look into this? We’re blocked from releasing with Juce6 at the moment and we’re about to roll back to Juce5.
Much appreciated

[ed95]

Thanks for the report. Unfortunately we need that condition with high-DPI plug-ins on Windows as it guards against the case where a plug-in window is moving between two screens with different scale factors and the bounds may be calculated using the old screen’s scale factor causing the UI to shrink/grow by the scale incorrectly.

However, we can get away with making the check much stricter which will still fix this issue but gets rid of the black bars that you are seeing when resizing in some hosts. We’ve added this to develop in 5fc20f7 - we’ve tested this in a number of hosts but please let us know if the issue persists.

[jakemumu]

Hey @ed95 -

I cherry picked that change into my local JUCE repo, but I’m still seeing the frame resize without the plugin on windows ableton vst3

It seems the edge case this is solving is much less priority. thanks @haroldgroenenboom for hunting down the problem. I think for now we’re gonna remove this patch since most users notice the plugin not sizing with the windows, while dragging between monitors is a bit more rare.

[ed95]

Hm, that’s a shame. Can you try with the tip of the develop branch? There were a few other Windows VST3 fixes lately which may help.

Does your plug-in use a fixed aspect ratio (ie using ComponentBoundsConstrainer::setFixedAspectRatio())?

[jakemumu]

Giving that a shot now. I’m not positive if this is still the recommended way to manage things but in the editor:

setResizable(true, true);
getConstrainer()->setFixedAspectRatio((double)mOriginalWidth / (double)mOriginalHeight);
getConstrainer()->setMinimumWidth(mOriginalWidth/2);
getConstrainer()->setMinimumHeight(mOriginalHeight/2);

in the resized:

float scale_factor = (float)getWidth() / (float)mOriginalWidth;
auto transform = AffineTransform::scale(scale_factor);
mMainView->setTransform(transform);
mMainView->setTopLeftPosition(0, 0);

There’s 2 draggable components on the window when you do set resizable this way. The window itself has a draggable corner from the os (I would guess) and the juce editor itself has the corner. You’re able to drag both the JUCE component, and the OS window corner. When you drag the OS window corner, the plugin does not resize with that block of code in the VST3 & VST resize functions.

Dragging the actual plugin window corner always behaves as expected, and snaps the OS window frame to the dimensions of the plugin window.

[jakemumu]

I just tried from develop and it’s not totally fixed (at least for me). It’s still possible to create a black edge around the window, but at a certain point the plugin window itself catches up and snaps to the frame (sometimes). The black edge though is larger than I would expect than anything multiplied by 0.001

Side note – I am running the windows OS in a Parallels virtual machine on a MacBook Pro (if that’s any help)

This bug was confirmed though with beta testers on standard win builds

[ed95]

There have been a few more high-DPI fixes on develop and we’ve refactored out the aspect ratio check completely now -

VST3: Improved stability of scaled plug-in windows

VST/VST3: Removed a workaround for checking whether DPI-aware windows were incorrectly scaled in editor resized() callback

Please pull the latest and let us know if it fixes things for you.

[scopedaudio]

Hi Ed, thanks for work on this. Live10 on windows now scales correct if you drag the bottom right corner. However, you can resize from any other side/corner as well and this produces glitches. Live10 on mac works perfect.

[ed95]

Thanks for the report, this should be fixed on develop now.

[hgroenenboom]

Hi Ed, thanks for looking into this!

The previous issues I posted above are completely fixed on Fl Studio and Ableton on my windows machine !
There is still one issue left:

Whenever I resize from any other than the bottomright corner and I reach the constrainer size, the window starts moving along where I drag.
FL Studio

Ableton

Aside from that I actually don’t want to have resizing from all corners, so an easy fix for me would be using setResizable(false, true);. But making the first boolean false disables the resizable corner for the plugineditor.

I would love to be able to not use the host-resizer (disable resizing from the VST3 canResize() call), enable resizing in JUCE and use the JUCE ResizableCornerComponent already integrated in the PluginEditor.