There is a strange issue with UADx plugins when opened on a scaled screen on Windows.
This can be reproduced in JUCE AudioPluginHost (JUCE master 8.0.14) with any UADx plugins, e.g. “UADx 610-A Preamp and EQ” with Windows scaling set to anything else than 100%.
When loading the plugin and opening the GUI for the first time, the GUI comes up correctly.
The UADx plugin appears to be a JUCE plugin that embeds a Chrome window. VST3 plugins can receive custom scale factor requests from the operating system. Currently, a JUCE VST3 host will normally send a scale factor of 1.0 immediately after displaying a window, and will send the ‘actual’ scale of the screen shortly afterwards. My guess is that the plugin isn’t handling this sequence quite right, and is failing to update the Chrome window bounds after the scale factor gets changed the second time around.
As for why the plugin works in other hosts: the hosts you mentioned seem to send the actual display scale factor immediately, and avoid sending a redundant scale of 1.0 first.
I’m not sure whether this counts as a bug in the hosting code, since a robust plugin should be able to handle what JUCE’s hosting code is doing. i.e. the plugin should be able to accept arbitrary scales from the host, which might even include scale factors that differ from the display scale. However, we may be able to adapt the hosting code to behave more like the other hosts you mentioned, which might in turn fix the UADx display issues.
Thanks for that insight!
It would be great, if this issue could be fixed on the JUCE side somehow.
But maybe you also have a possibility to contact Universal Audio as a JUCE customer, to clarify who should fix it.
Furthermore, I found out, that there is a similar but even worse problem when using the DSP hardware based versions of the UAD plugins. Their GUIs are much smaller on a scaled Windows screen than the native UADx versions, so they seem to be not scaled up at all.
When moving these GUIs from a scaled to an unscaled screen (or vice versa) they completely freak out: The Window permanently changes between a large and a small size and the computer becomes unusable. This state could only be stopped using the Task Manager.
Do you know which version of the UA plugins you have installed? I had version 11.0.1 of the “DSP Plug-Ins & Drivers” package installed and wasn’t able to reproduce this behaviour. There was an update available (11.9.0), and I still wasn’t able to reproduce the behaviour after updating.
What scale factor are you using on your scaled display? I’ve tried 150% and 125%, testing with the primary display set to both the scaled and the unscaled display (i.e. 4 different configurations). I opened the UA 610-A plugin, and the behaviour I saw was a bit buggy, but not in the way you described.
When the plugin opens on the unscaled display, it initially displays at the appropriate size and scale. When it moves to the scaled display, the window is resized to the correct size, but the content is not scaled, leaving a border on the right and bottom sides of the window.
When the plugin opens on the scaled display, it again initially displays correctly. When it moves to the unscaled display, the same thing happens again: the window is resized (smaller this time), but the content is not scaled, so some of the content gets cropped.
I also see the same result in Cubase 14, so this is almost certainly a bug on the plugin side. It looks like the content is not responding correctly to scale factor updates after it is initially shown. I’d recommend logging this as a bug with UA.
Result after moving from unscaled to scaled display, AudioPluginHost:
I may have spoken too soon - I think that the plugin editors are not changing physical size after switching between displays, but both Cubase 14 and the AudioPluginHost are expecting the editor to change size proportionally. The behaviour is better in Cubase 15, where the host window matches the plugin editor bounds more closely. I’ll try to rectify the AudioPluginHost behaviour.
I have checked the version on our UAD-DSP system and found that “DSP Plug-Ins & Drivers” was on version 11.5.2 here. I have updated this to the latest 11.9.0.
After this update, the flickering problem when moving the plugin between the 2 screens has gone.
I can confirm, the wrong scaling in Cubase when moving the plugin window from one screen to the other. But when closing and re-opening the plugin Window in Cubase, it is always completely visible.
The problem that the GUIs of native UADx plugins are cropped when opening them for the second time in JUCE AudioPluginHost still remains. This issue could not be reproduced in any other host so far.
Thanks. I’ve spent a bit more time debugging the DSP plugins in the AudioPluginHost. I think there is (arguably) a bug in the DSP plugins, which is that IPlugView::checkSizeConstaint doesn’t seem to be implemented correctly.
Normally, the host calls this function to check whether the plugin editor supports being set to a particular size. If the editor doesn’t support the requested size, it’s supposed to modify the passed-in rectangle to the closest supported size.
The DSP plugins only seem to have a single supported size, so their implementation of checkSizeConstraint should always modify its argument to match that supported size. In reality, we see that the plugin doesn’t modify the passed-in size at all, which means that the host is allowed to assume that any arbitrary size is supported.
I believe the buggy behaviour we see in the AudioPluginHost happens because of the following sequence:
The editor moves between displays.
The system estimates new bounds for the window based on the DPI of the new display, and sends a WM_WINDOWPOSCHANGING message to the editor’s peer.
The peer can accept or modify the proposed bounds. The peer implementation passes the request on to the peer’s ComponentBoundsConstrainer; in the case of the PluginWindow, there are a few layers of constrainers, ending at the constrainer of the VST3 editor itself.
The VST3 editor’s implementation of ComponentBoundsConstrainer::checkBounds() passes the request onto IPlugView::checkSizeConstraint, which incorrectly approves the new size.
Since the peer’s constrainer has approved the size, Windows updates the plugin editor window to the proposed size, cropping the edges or adding a new border on the right and bottom of the editor.
We could fix this on the hosting side by retaining the existing side instead of calling “checkSizeConstraint” if the plugin editor reports that resizing is unsupported - that might fix things in this case, but I’d be worried about it having unforeseen consequences for other plugins.
Unfortunately, I could not really reproduce that modifying the checkBounds() function you mentiond changed anything.
On the other hand, I found out, that activating the “Auto-Scale Plugin Windows” option in AudioPluginHost makes it possible to move the window of the DSP-Plugins from one screen to the other without cropping. (I had already tried that before, but I was not aware that I would need to restart AudioPluginHost to make it happen.)
What still remains is the initial problem that the native UADx plugins still get cropped when re-opening the GUI on a scaled screen, as described in my first post.
I found that this might also have to do with UADs copy protection. If the plugin is not licensed, the GUI is blurred. In that case, the blurred GUI can be re-opened without cropping multiple times.
If the plugin is licensed, the GUI is initially blurred and is faded to non-blurred. After that the non-blurred GUI is always cropped when re-opened, as shown in my screenshots above.
Any hints, how this could be solved on host side would be welcome.
I will report that bug to UA. If you have any direct contact to their development department, maybe you can also try to tell them about it.
