With the recent hiDPI support changes things have gotten a bit better looking, but some things are still broken. This is on Windows 10.
If you open AudioPluginHost on a hiDPI screen (I assume anywhere where scaling factor is not 1) and try to open the UI for any of the Arturia plugins like Wurli (or any other Arturia V or VI collection plugin)- it comes up with the container window scaled x2, but the plugin itself is not scaled. The menu for the plugin is scaled, but invisible until one blindly clicks in the upper left corner (see picture)
This is for both VST2 and VST3 versions of these plugins.
Regular DPI screens work, but this is a fairly big issue as more and more devices come with or use hiDPI screens.
I tried opening these in Cakewalk for example and they show up perfectly fine on the same machine.
I noticed a hack for “Kontakt” in the plugin window class which does not disable the the DPIAwareness, but that results in a different behaviour.
I’m sure that there are other plugins with similar issues. Is there any chance a “hiDPI expert” can take a look at this ? I can help with anything that needs testing or trying out.
Have you enabled DPI awareness for the plug-in by right-clicking on the node and selecting the menu option?
That does the same thing as the “Kontakt” hack I mentioned above. It does work better. VST3 window seems to come up ok, but the VST2 window comes up half the height approximately and cuts off bottom half of the plugin.
While the picture below may look ok at the first glance - there is an entire pedal area below the keys that is missing.
Is there a way to better handle this? You have to admit that code like this
if (node->getProcessor()->getName().contains ("Kontakt")) // Kontakt doesn't behave correctly in DPI unaware mode...
just looks wrong.
The default should be to somehow handle this so that things work the old way, but then allow the user to change it. This was the intention I guess with the menu item, but there’s obviously something wrong if code like this has to be there.
I may be completely wrong though and enabling the hiDPI awareness does something irrecoverable to the plugin windows.
Unfortunately, handling DPI-awareness correctly on Windows is not an easy task and it only becomes more difficult when you are hosting plug-ins which may behave differently depending on the context in which they are opened. The scaling in the JUCE hosting code is based around the scaling APIs that are available in the VST2 and VST3 specs but many plug-ins don’t implement this, or have their own workarounds for rendering at high resolutions which interfere with this so it’s a total minefield. The JUCE DPI-aware scaling code has been tested with a lot of plug-ins, but there are plenty of edge cases and weird behaviour, and it’s far from perfect - we’d certainly welcome any suggestions for how to improve things.
To get the old non DPI-aware behaviour back, you can recompile the plug-in host with the
JUCE_WIN_PER_MONITOR_DPI_AWARE flag set to 0 in
Right - thank you. I am aware that this is not an easy task and I really appreciate the efforts.
I wish the solution was as easy as simply disabling the new stuff with the
Unfortunately - then you get the different behaviour where every plugin looks tiny on a hiDPI screen and is unusable.
Cakewalk is not hiDPI aware as far as I know, but it manages to properly display the plugins.
In the image below the normal size Wurli is hosted within Cakewalk while the mini Wurli with the unreadable text is in Tracktion or AudioPluginHost with that flag disabled (
So I still maintain that there is something intrinsically wrong with how hiDPI stuff is handled on windows. Especially when it comes to disabling it.
In any case - I think it’s ok to say that the hiDPI plugin hosting on Windows does not really work well yet in JUCE 5.4.
I hope things will improve soon and again - if there’s anything I can help with - I’m game.