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.
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.
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!
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
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.
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:
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.