GUI update VST: knobs don't move

[FWL]

Hello Saga,

Recently I've noticed in Openmpt that a lot of vst and vsti plugin don't update their GUI after adjusting a parameter. Some get updated after closing the vst window and reopening. Some update after clicking another parameter. Examples of free plugins that act this way for example are:

Vsti:
Crystal 64bit
Model E VSt 64bit
Phosphor

Vst:
ADverb
Replicant

Magware:
DuneCM
AlphaCM
PhonecCM
(a lot of the CM-studio plugins have this issue)

If I recall correctly this issue wasn't that prominent in the past. Have you any ideas what could cause this?

Thanks in advance!

Version              : latest OpenMPT (amd64 (64 bit)) Version 1.31.04.00
System Architecture  : amd64
CPU                  : GenuineIntel, Family 6, Model 142, Stepping 10
CPU Name              : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
Available CPU features: amd64 mmx sse sse2 sse3 ssse3 sse4.1 sse4.2 avx avx2
Operating System      : Windows 11 22H2 (Version 10.0 (Build 22621))

[Saga Musix]

If I recall correctly this issue wasn't that prominent in the past. Have you any ideas what could cause this?

I am not aware of any such issue.

I did a quick test with Crystal (the only plugin from that list I have) and both the 32-bit and 64-bit version, no matter if bridged or not, update their GUI as they should. OpenMPT has no doing in this - it tells the plugin to set the parameter to specific value, then it's the plugin's job to redraw the UI. Of course it is a possibility that older plugins have issues with Windows 11 (I'm still on Windows 10). Do you see similar problems with other VST hosts?

[FWL]

Hello Saga,

The plugins work in Reaper 4.78 and in Waveform 12 free. But I tried the plugins bridged like you did and than the GUI responds as it should. Maybe that's the easiest solution. Does this cause a lot of extra cpu load?

[FWL]

And with that I mean 64 bit plugins bridged.

[Saga Musix]

Have you tried using the plugins one by one (i.e. just load one instance of one plugin and make sure no other songs are open in the same instance)? Because it sounds strange to me that so many plugins would expose the same issue. It could be a problem caused by a single bad plugin that is spamming the message queue, thus breaking UI rendering for all other plugins. Using the plugin bridge causes a plugin to have its own message queue for window events, which would explain why the GUI works as expected then. Also if you have smooth pattern scrolling enabled in OpenMPT, try disabling that to see if it makes a difference, and also try increasing the update period in OpenMPT's sound card settings to see if that changes anything.

Does this cause a lot of extra cpu load?

The plugin bridge doesn't add any CPU load per se (you will not see much higher CPU usage in Task Manager, for example), but it means that OpenMPT's audio thread has to wait for the results of the bridged process to become available. Waiting for a result doesn't cause a CPU load, but it still causes overall rendering of the audio to take longer, so especially with low-latency audio (e.g. with ASIO drivers), you may experience increased amounts of pops and crackles when using many bridged plugins. But on a modern system a handful of bridged plugins shouldn't cause any problems.

[FWL]

The things you suggested don't have an effect on the issue. But I just downloaded version 1.28.01 64 bit portable from the archive. And crystal and DuneCM do function as normal in that version. It's weird.

[FWL]

I've tried some more version and the breaking point is between version 1.28.10 and 1.29.01. i've downloaded both 64bit zip version. Crystal works in 1.28.10 unbridged and doesn't work in 1.29.01.

[Saga Musix]

Looking at the 1.29 changelog, I found only one candidate for the change in behaviour and indeed it does seem to be related: Starting from that version, OpenMPT asks Windows to use a nicer-looking upscaling method when rendering its UI on screens with a scaling factor above 100%. So changing my display scaling to 150% now, I can see the same problem, but not at 100%.
There is currently no way go back to the old, more blurry scaling, but what you can do instead is turning on DPI-awareness in OpenMPT by going to Advanced settings and setting the "HighResUI" setting to 1 and restarting OpenMPT. This will render OpenMPT's UI directly at the DPI setting configured in Windows. Some things to keep in mind when doing so:
- You may have to choose a bigger pattern font if it's too small after this change
- GUIs of older plugins (like the ones that you mentioned) are typically not DPI-aware, so they will look a lot smaller now. There is no way around that unfortunately. Windows' built-in screen magnifier might help with very tiny plugin UIs.

If using HighResUI mode is not an option for you, I'll see what can be done to disable the nicer-looking upscaling mode, or if there is a simpler workaround that only affects VST plugins (but I doubt it because they draw their UI entirely by themselves, so OpenMPT has little influence over when and how they redraw the UI).

[FWL]

Thanks for looking in to this Saga! I wasn't aware that I had a screenscaling on of 125%. This has probably happened when I detached my external monitor and differing resolution settings or something like that. I reverted back to 100% now and everything works fine. So for me the problem is solved. Thanks again!

[n0cturn]

Wow, this has been bugging me for ages, I thought it was a problem with my system, but the HiresUI trick has worked a treat. Thanks.