Cubase 10.0.10 - Win 10 - VST3 HDPI Bug

[edintell]

Using the latest Juce 5.4.1 I’m encountering the following issue by using Cubase 10.0.10 on Windows 10:

If HDPI in Cubase is activated and the Windows-Screen-Scaling is set to a value > 100% (e.g. 125%, 150%, etc.) then the rendering of the VST3 plugin gets corrupted.

The following screenshot shows the perfectly rendered plugin at 100% screen scaling (pls. see code below).

At 125% screen scaling the component size stays at 500 x 300 and the content seems to be correctly scaled by a factor of 1.25. Therefore, part of the content is just not visible.

It gets worth at a scaling of 150% where a white frame of a size of 1000 x 600 pixels appears, but the content is correctly rendered at 750 x 450 (Factor of 1.5).

Well, the issue could be with Cubase or JUCE.
It seems that the content of the plugin is always correctly scaled but the rendered view varies greatly.

VST 2.4 is heavily impacted too by just collapsing the view if resized. Nevertheless, the support has been dropped anyhow.

#include "PluginProcessor.h"
#include "PluginEditor.h"

//==============================================================================
ResizeTestAudioProcessorEditor::ResizeTestAudioProcessorEditor (ResizeTestAudioProcessor& p) : AudioProcessorEditor (&p), processor (p)
{
    setResizeLimits(200, 200, 1000, 1000);
    setSize (500, 300);
}


ResizeTestAudioProcessorEditor::~ResizeTestAudioProcessorEditor()
{
}


void ResizeTestAudioProcessorEditor::paint (Graphics& g)
{
    int width = getWidth();
    int height = getHeight();
   
    g.setColour (Colours::white);
    g.setFont (15.0f);
    
    g.fillAll (getLookAndFeel().findColour (ResizableWindow::backgroundColourId));
    g.drawRect(0, 0, width, height, 1);
    
	g.drawText("Width: " + std::to_string(width), 0, 100, 200, 20, Justification::right);
	g.drawText("Height: " + std::to_string(height), 0, 130, 200, 20, Justification::right);
}


void ResizeTestAudioProcessorEditor::resized()
{
}

[ed95]

AFAICT, we’re doing the correct thing and the problem is that Cubase 10 doesn’t seem to properly support non-integer scale factors. I’ve put a breakpoint in this method and we get the following, where the LHS is the Windows display scale:

• 100% = 1.0
• 125% = 1.0
• 150% = 2.0
• 175% = 2.0
• 200% = 2.0

So you can see that the plug-in will only render correctly for display scales of 100% or 200%, everything in between will result in the behaviour that you’re seeing. Other DPI-aware DAWs seem to get this right and report the correct scale factor so it looks like this is a Cubase issue.

[edintell]

Thank you ed95!
I’ve just reported your findings to the Steinberg developer team.
Hopefully we’re getting a fast solution.

[edintell]

Dear Ed95,

I’ve got the feedback from Steinberg that Cubase is only able to handle integer based scaling.
Do you see any chance to implement a workaround for that behavior?

Quote:
“this is not a bug, Cubase only supports integer scaling and reports this also to the plug-ins. You’re free to ignore the scaling factor Cubase sends to your plug-in if you handle the DPI changes yourself.”

In fact they state that Cubase provides the information about its scaling and it is up to the plugin to decide whether it should scale on the reported scaling from windows or the host. In both cases it is the plugin’s responsibilty to request the correct screen size.

I hope you guys have an idea how to handle this.
From my point of view it would be great to fetch the correct HDPI scaling from Windows directly.

[ed95]

VST3: Check for non-integer scale factors when running in DPI-aware Cubase 10

[ed95]

The VST2 issues should be fixed by these commits:

VST2: Fix scaling bug in hosts which don't support the sizeWindow call

VST2: Default to main monitor scale factor in plug-in editor's constructor to get correct size when opening in Cubase 10

[edintell]

Thank you very much for the extrem fast fixes.
Please give me some time to test them.

[edintell]

In generel the fix works partly for VST3 and VST2.4.

Issue in VST3:
There is only one misbehavior with VST3 which does not appear in the VST2.4 version.
If the windows scaling is set for example to a value of 150% or 175% and the GUI is opened or closed and opened again it appears with a larger size (Factor 2 = 200%) and needs to be manually resized to its smaller size of 150% or 175%.
Well it seems that it scales to the integer scaling factor Cubase provides but it would be great to scale to the windows scaling and report the necessary plugin size to the host.

Issue in VST2.4:
During resizing it happens that the window is getting smaller and smaller until parts of its content disappear at the bottom and the right border. That is not observable in the VST3 version.

Do you see any way to work around that problem?

[ed95]

OK, I’ve just pushed a couple of commits to the develop branch - let me know if it fixes the issue.

During resizing it happens that the window is getting smaller and smaller until parts of its content disappear at the bottom and the right border. That is not observable in the VST3 version.

I can’t reproduce this with the JUCE AudioPluginDemo. I did observe some flickering when resizing however which should be reduced with this commit - perhaps the two issues are related?

[edintell]

The Cubase 10.0.10 VST2 resizing issue is unfortunately still there.
I’ve just used the default audio plugin with a full frame rectangle to see whether the frame stays at the same size. Well, it just shrinks during resizing.
I’m doing the resizing (larger <-> smaller) a couple of times and the rendered view is getting smaller and smaller.

I can confirm that the 5.3.2 AudioPluginHost - that supports VST2 - does not show that behavior.

++++++++
Just as a side note: The AudioPluginHost reacts correctly if the plugin resizes itself to a smaller size by adapting the overall plugin window just for VST2 but not for VST3 where the window stays at its original size and fills the empty area with black.
Well, VST3 programmatical resizing worked in older AudioPluginHost versions.
++++++++

Do you have an idea how to handle the VST3 HDPI sizing?
Its not that nice that any time the GUI is opend the plugin appears at 200% (Cubase Scaling Factor) and needs to be resized manually to for example 150% (the set Windows Scaling).

Thanks for your great support!

[ed95]

How are you resizing the AudioPluginDemo? I can’t reproduce this by dragging the bottom-right corner resizer.

[edintell]

Most likely I did not describe the use case correctly.
Keep in mind that the test needs to be execute on an HDPI display where the Windows screen scaling is set to for example 150%.
If you use a normal display at 100% then everything looks fine.

Plugin after GUI launch:

Plugin GUI after resizing (please see code below):

Its even worth if you deactivate “Always in foreground” (Cubase selection menu in the upper right corner of the plugin). In that case the plugin suddenly scales to 100% and is not resizable anymore.

Honestly, because VST2 is not supported by Steinberg anymore it is more important to fix the VST3 behavior.

#include "PluginProcessor.h"
#include "PluginEditor.h"

//==============================================================================
ResizeTestAudioProcessorEditor::ResizeTestAudioProcessorEditor (ResizeTestAudioProcessor& p) : AudioProcessorEditor (&p), processor (p)
{
    setResizeLimits(400, 400, 2000, 2000);
    setSize (400, 400);
}


ResizeTestAudioProcessorEditor::~ResizeTestAudioProcessorEditor()
{
}


void ResizeTestAudioProcessorEditor::paint (Graphics& g)
{ 
    int width = getWidth();
    int height = getHeight();
	int offset = 10;

    g.setColour (Colours::white);
    g.setFont (15.0f);
    
    g.fillAll (getLookAndFeel().findColour (ResizableWindow::backgroundColourId));
	for (int i = 0; i < 4; i++) {
		g.drawRect(i * offset, i * offset, width - 2 * i * offset, height - 2 * i * offset, 1);
	}
	g.drawText(std::to_string(width) + " x " + std::to_string(height), width / 2 - 50, height / 2, 100, 20, Justification::centred);
}


void ResizeTestAudioProcessorEditor::resized()
{
}

[ed95]

Are you sure you’re testing against the tip of the develop branch? Have you done a clean build and made sure that Cubase is instantiating the new build of the plug-in? The commit that I posted above should have fixed the incorrect initial scale factor for VST3s

[edintell]

I’ve just verified everything:

1.) I’ve pulled the latest commit from the development branch

2.) Building of the projucer.exe
3.) Pointing all pathes to the modules of the development version.
4.) Building the VST3 version
5.) Starting Cubase 10.0.10 on an HDPI display at 150%

Opening or re-opening the plugin GUI creates the following view by using the code above (Scaling by 2 / Cubase Scaling):

In a second step it is possible to resize the GUI to the correct size:

Well, the expected behavior would be a scaling depending on the Windows scaling. Which should be a factor of 1.5 and then it shouldn’t be possible to resize the view to a smaller size.
Shouldn’t the plugin still have an initial size of 400x400 even if the windows scaling applies a factor of 1.5 or Cubase in this case an HDPI factor of 2?

As a side note:
The situation gets a bit worse if a second display with a different resolution is connected, but that shouldn’t be discussed here and is most likely caused by Windows itself.

Do you use the latest Cubase version for your testing?

[yfede]

OT: a side note, entirely meant to be constructive feedback: I guess you’re using the word “worth” (= “valued / of value”) in place of “worse” (= “more than bad”).

They sound almost the same but their meaning is almost opposite. that got me confused at first, so that may also mislead some other non-native speakers

[edintell]

Thanks for your heads-up. I’ve just corrected it.

[ed95]

VST3: Added a workaround for Windows DPI-aware Cubase 10 opening plug-in editor with double scaled bounds

[edintell]

Unfortunately, I’m not able to test your fix because the latest development build Projucer does not allow to set the Runtime Library to static. It always falls back to “Default (Use dll runtime)”. That still works in 5.4.17.
As soon as I’m able to set my project back to “Use static runtime” I’m able to test your fix.

[ed95]

I’ll look into that, but for the time being you don’t need to rebuild the Projucer to get these changes.

[edintell]

I’ve tested with the Projucer 5.4.17 and your new modules and it looks good.
The plugin always opens correctly sized in the scaling set by Windows.
Thanks for your great work.
It just acts a bit weired in a multi monitor environment with different resolutions, but here I’m blaming windows.