Plugin UI for HiDPI Windows for Live

We’re still working on it, but “soon”.

It’s a surprisingly difficult problem.

2 Likes

I don’t doubt that at all.

thx for the update

Yep, what Tom said. Don’t want to make any concrete promises but hopefully fairly soon.

2 Likes

Hello there,

I am new to this forum and to JUCE - I was about to ask this same kind of questions in my first post but then, after a search, I realised that the topic is already being discussed.

I am working on a simple bit-crusher plugin (after going through some JUCE tutorials and other learning materials) and I noticed that, while the standalone version gets the correct scaling automatically, the plugin does not (well, at least in Live 10 and JUCE’s Plugin-Host… as I just realised it seems to work fine in FL Studio 20!).

Initially, I assumed developers must handle scaling themselves, but after reading the forum (and noticing that it works in FL Studio) I now wonder what’s the general recommendation/best practice? Is the idea that scaling is completely handled by the framework? What about those cases in which we want an explicit “zoom” functionality (I’m thinking e.g. about Serum, which can be zoomed freely by dragging the bottom-right corner)? Are there any general guidelines?

Thank you and sorry if I posted in the wrong place :slight_smile:

I’m a little lost on this, too. We’re switching from VSTGUI, and have two sets of graphics, one at normal size and one at double size. Do we still need that? And if so, how exactly do we implement which set of graphics is to be used in our paint routines (some of which are entirely Projucer-generated)?

1 Like

Btw, I initially didn’t notice this post from a couple of days ago:

I just tried building my plugin using the latest develop branch and it now seems to scale correctly in Live 10. However, the plugin still looks tiny (not scaled) when I open it with PluginHost - not sure why.

I am not using any images (just the default JUCE widgets) so I guess it’s OK if the framework takes care of all the scaling at this stage (since those controls are vector-based and there’s no need to switch images etc.). I have no idea how all that is supposed to work with images though (but I suppose it’s hard given that only few existing plugins seems to support HiDPI?).

Have you also rebuilt the plugin host?

Ah that’s right! I only built the PluginHost in master, but not in develop.

I am trying to build it now but I got compile errors (it only happens in the develop branch, not in master, I tried to switch a couple of times) :disappointed:

Can you try also rebuilding the Projucer from the develop branch and then re-saving the AudioPluginHost.jucer file with it? Make sure that the “Custom VST3 SDK” field is blank in the File->Global Paths... menu.

I am trying to rebuild the Projucer but I am getting this:

Error MSB8036 The Windows SDK version 10.0.16299.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".	Projucer_App	C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\x64\PlatformToolsets\v141\Toolset.targets	36	

Actually, this is not new to me: I get this every time I start a new project, but I usually fix it by manually setting the SDK version to 10.0.17134.0 (the one that apparently my system is using) in the Producer/exporters/VS2017 options.

Now I do not have a Projucer anymore (I accidentally remove the build) so I am not sure how to set this. I tried “retarget solution” in VS2017 but it seems to have no effect (unless I’m missing something)…

You can install the 10.0.16299.0 SDK by opening the VS installer and selecting ‘modify’ under 2017. There should be an option for the SDK under ‘individual components’.

Thank you, I found the option in the VS installer. I’ll try it out on Friday and will let you know if it all works after I rebuild both the Projucer and the PluginHost (the SDK is ~6 Gb and unfortunately I’m currently on mobile data until they activate the new broadband on Friday :frowning:)

EDIT: 6 GB was actually the total size of VS installation after adding the new SDK. The SDK itself should “only” be 3 GB or so :slight_smile:

Hey @ed95 sorry for the delay - finally got my broadband (I just moved!) and managed to download and install the missing SDK.

As discussed the other day, I rebuilt the Projucer from the develop branch, and then the AudioPluginHost (using the newly built Projucer). Everything is building just fine now. I then built my plugin again and checked what it looks like in Ableton VS PluginHost.

In Live 10 is the same as before - it looks fine:

Now the interesting part: in PluginHost, it now appears to be of the right size (it’s not tiny anymore as it was before rebuilding the PluginHost in develop). However, it doesn’t look as good as in Ableton; it appears blurred, as when you take a photo and zoom it at 200%…

bad

Let me know if you need any more info!

You need to right-click on the plug-in node in the UI and select ‘enable DPI awareness’ otherwise the default is to open in non-dpi aware mode.

Ah! Yep, that’s right. Looking good now, thanks! :smile:

Hi Juce Team,

Could you maybe talk to Ableton to figure out whether there is a way to make Live know a plugin is dpi aware so users don’t have to change that setting? Then you could use the same mechanic for the Juce Audio Plugin Host.

Should the enable DPI awareness be stored when you save the filter? I’m having to enable it each time I run up the pluginhost.

Are you running the latest beta? They’ve done quite a bit of work on HDPI

Absolutely… what I mean is some mechanic to have hosts automatically detect whether a plugin is hi-dpi capable. Right now, both in Live 10 and the Juce Demo host users have to manually enable hi-dpi mode. I’m guessing Ableton Live has some internal method maybe that could be shared with Juce… or the other way 'round.

ah yes, i see - i totally forget about enabling that in Live…