I’m running into an issue that I can so far only reproduce with Kilohearts Phase Plant on VST3/Mac.
Seems like loading this plugin in AudioPluginHost shows the wrong plugin size. I see that behavior in both APH, Tracktion Waveform 12/13 and my own hosting code.
Ableton Live, however, shows the plugin correctly.
It looks like Phase Plant may actually require the setContentScaleFactor API in order to display at the correct scale. I’m not aware of any other macOS plugins that use this API - as far as I know, macOS plugins tend to use the scale factor exposed by the CoreGraphics context or NSWindow backingScaleFactor rather than relying on the host to provide the correct scale.
Please could you try adjusting the definition of setContentScaleFactor in juce_VST3PluginFormat.cpp to match the snippet below and check whether that allows the plugin to display at the same scale? It would also be helpful if you could test any other VST3s you have installed.
It seems to work properly with all the VST3s I’ve tried out here, but I’m not sure whether it’s correct according to the spec. It would be nice if the docs for IPlugViewContentScaleSupport described the expected behaviour of this interface on macOS.
void setContentScaleFactor()
{
#if ! JUCE_MAC
if (scaleInterface == nullptr)
return;
[[maybe_unused]] const auto result = scaleInterface->setContentScaleFactor ((IPlugViewContentScaleSupport::ScaleFactor) getEffectiveScale());
[[maybe_unused]] const auto warning = warnOnFailure (result);
#endif
}
Thank you Reuk! This fix looks great on Phase Plant and all other plugins I’ve tested so far.
(Diva, Serum, Vital, Keyscape, Polyverse plugins, Fabfilter plugins, NewFangled audio plugins… Waves).
I did test only on Mac and it seems like this code makes some changes to the non-Mac code path too, right?
I believe it should only have an effect on macOS. I moved some stuff around, but the runtime behaviour should be unchanged on other platforms.
I believe this is technically a bug in Phase Plant, but I can’t find anywhere in the VST3 docs that really spells this out. I’ve opened a thread on the Steinberg forum asking for clarification here:
The downside of the workaround I suggested is that it will break applying custom scale factors to VST3s on macOS, so it won’t be possible to e.g. create a “zoom” control in a hosting app. I believe that the current behaviour of Phase Plant when provided with a scale factor of “1.0f” is incorrect. As such, I’m not sure whether it’s better to merge this workaround, or to file a bug report with Kilohearts, perhaps after the VST3 docs have been updated.
Thank you!
It it is important to mention that all other non-JUCE DAWs I’ve tested so far (Cubase, Ableton Live, Reaper, Bitwig) all show the window size correctly, so I’m guessing there’s some form of ‘recommended practice’ here?
Something else to notice. Steinberg have their own “EditorHost” app in the SDK.
This app doesn’t show the bug as well. I placed breakpoints in all the calls and implementations of setContentScaleFactor() and even though there does seem to be a call to it - I don’t think it’s hit.
I see similar behaviour in the VST3PluginTestHost from Steinberg.
The docs for IPlugViewContentScale say (emphasis mine)
the host calls setContentScaleFactor directly before or after the plug-in view is attached
I can also get the “correct” behaviour in Phase Plant + AudioPluginHost by only calling the function before attach, rather than after. Maybe that’s what other hosts are doing. It definitely seems like a bug if Phase Plant can’t handle the scale factor being set after attach, which is explicitly allowed in the VST3 documentation.