Cubase 10.5.20 Maintenance Update

I just updated from 10.5.0 to 10.5.20 and seems to be working ok so far on Macbook Pro running OS 10.14.6. That was not my experience with 10.5.12. I’ll report if there are any issues I come up with.

No hiDPI for Windows versions yet I see.
Over 20 years of dedication to your company and I am realizing maybe further dedication to you may be a mistake.
It’s time to take a serious look at Studio One.

Hi,

Could you try in Cubase Safe Start Mode [Disable preferences], please? Just to confirm or disprove it’s a preferences issue.

Hi,

Are you on Mac or Windows, please?

Hi,

Cubase 10.0 and Cubase 10.5 are independent applications, they event don’t share the preferences. So it’s hard to imagine Cubase 10.5 installation would affect Cubase 10.0.

What eLCC version do you use, please?

Hi,

This is broken since Cubase 10.5.0. It’s known and already many times reported issue. Thank you.

Does this bug exist in 10.5 ? https://steinberg.net/forums/viewtopic.php?f=286&t=190347
Its very important fix for my work

Hi there,

Our QA is on it and will check if they can reproduce the issue.

Thanks for the report,
Matthias

Hi,

This change was intentional to improve the consistency of these type drop down selections. I will talk to the team about your feedback.

Thanks,
Matthias

We are still working on it. It’s not a quick win and the scaling needs a lot of testing and refinement though. Unfortunately there won’t be any improvement before Cubase 11.

It seems like a hick-up in the prefs. Have you tried to delete your preferences?

I’m not believing what I am reading right now. :neutral_face: Anyone ever heard the saying “IF IT ISN’T BROKEN DON’T FIX IT”?

Huh! But we’ve already bought it as it was advertised 18 months ago! Does that mean that cubase 11 will be a free upgrade for people who’ve already bought Cubase 10 HiDPI when it was releasd? And what about eucon? 4-1/2 years down the line and still no update!

Please bring this functionality back as an option. I use it numerous times during each session, so much so that I rolled back to the previous version.

Thank you Matthias for your answer, really appreciate it and looking forward to it :slight_smile:

First, all the respect to u. I appreciate that you work hard, but I hope that you are joking because in this way you will lose your customers.
Do you expect customers to upgrade to Cubase 11 after we were tricked in10?
how will we work with this long period? We cannot run any additional components that are supposed to bring to us a free temporary solution


I expect that everyone will move to Studio one it in the future, just as you lost clients before, you will lose more.
u can’t spend more to solve this .? u can’t work more time to Programming .?
forgive me …

Thanks there is a small light at the end of this tunnel…

HOWEVER - I know engineers may say this is not quick, but as a CEO of engineers and a former programmer myself, this fix for HiDPI support of plugin windows is only a few dozen lines of code and a couple monitors for one coder. MAYBE another pair of eyes to help test all edge cases. I guarantee I could fix this issue in 3 days MAXIMUM.


Taking 2+ years to fix this for Nuendo/Cubase with potentially thousands of users complaining and ~10x+ not complaining but experiencing issues is driving everybody crazy. It damages reputation and sales during trial periods considerably.

Look at Windows API docs on DPI:

a simple function process like this is needed:

FUNCTION OnEditVSTInstrument or OnWindowMoved
GET MONITOR DPI (multi monitors)
ADJUST DPI
TEST

protected virtual void OnDpiChanged(DpiScale oldDpi, DpiScale newDpi)

Here is the latest Windows per monitor HIDPI API docs. Most of the HiDPI API for Windows was last modified in 2018.

https://github.com/microsoft/WPF-Samples/blob/master/PerMonitorDPI/readme.md

AND TESTING:

After you have updated your application to become per-monitor DPI aware, it is important to validate your application properly responds to DPI changes in a mixed-DPI environment. Some specifics to test include:

Moving application windows back and forth between displays of different DPI values
Starting your application on displays of different DPI values
Changing the scale factor for your monitor while the application is running
Changing the display that you use as the primary display, signing out of Windows, then re-testing your application after signing back in. This is particularly useful in finding code that uses hard-coded sizes/dimensions.

THAT’S IT!

At this point you just lost all credibility.

Really? You think scaling DPI on Windows opening and moving is hard?! I am currently the CEO of a company developing AR/VR applications using Windows/Unreal/Unity; before that I was a Microsoft certified programmer and database specialist and coded from when I was 7-25 years old. I was also the founder and CEO of a company I sold to Roland. Google me.

Sheesh.

Why don’t you read the Windows API examples how to do this, it is quite simple:

https://github.com/microsoft/WPF-Samples/blob/master/PerMonitorDPI/readme.md

I use that functionality all the time. if Steinberg/Yamaha are not able to fix this in 10.5 and will leave it on a TODO list for 11.0.x, then 11.0.x should be a free update to 10.5.x users.