Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLAP: Initial plugin size does not take scaling into account #447

Open
pawelulita opened this issue Feb 6, 2024 · 7 comments
Open

CLAP: Initial plugin size does not take scaling into account #447

pawelulita opened this issue Feb 6, 2024 · 7 comments

Comments

@pawelulita
Copy link

This is related to michaelwillis/dragonfly-reverb#151.

Screenshot_20240206_182111

The initial plugin size doesn't take into account the scaling factor the DAW gives it. If you use a scaling factor > 100%, the plugin window will be either too small or cropped. If the plugin supports resizing (e.g. Wolf Shaper), it can be solved by simply increasing the plugin window size. If not (e.g. Dragonfly Reverb), it can't be solved.

I can reproduce it in Reaper on Linux, but not in Bitwig.

Like I mentioned in the issue at the top, applying the patch below to DPF makes the Dragonfly Reverb plugins have the correct size in Reaper and doesn't affect it in Bitwig. However, I have no idea if this is just a hack that fixes the problem for this plugin, or if this is (part of) a proper fix for a bug in DPF.

This patch also fixes the problem for Wolf Shaper in Reaper and doesn't seem to have a negative impact on Bitwig.

diff --git a/distrho/src/DistrhoPluginCLAP.cpp b/distrho/src/DistrhoPluginCLAP.cpp
index 29a0316d..0ad05ccd 100644
--- a/distrho/src/DistrhoPluginCLAP.cpp
+++ b/distrho/src/DistrhoPluginCLAP.cpp
@@ -297,6 +297,9 @@ public:
        #ifdef DISTRHO_OS_MAC
         *width /= scaleFactor;
         *height /= scaleFactor;
+       #else
+        *width *= scaleFactor;
+        *height *= scaleFactor;
        #endif
 
         return true;
@falkTX
Copy link
Contributor

falkTX commented Feb 6, 2024

clap should behave the same as vst3 here, so check what the vst3 version is doing and compare.

the patch/diff you posted is indeed a heck, I am sure there is a deeper underlying issue at play here.

it might be that reaper does not support reporting UI scale while bitwig does, or vice-versa.
if you can do a build of the develop branch of dpf, and do some tests with the d_info example plugin, as it reports the host-side UI scale factor on its UI.

@pawelulita
Copy link
Author

d_info (from main) provides 2.0 as the scale for both CLAP and VST3 in both Reaper and Bitwig, which is consistent with the scaling factor set in the DAWs. For VST2, it shows 1.8 which is consistent with the global scale set by KDE, also both in Reaper and Bitwig.

Also, there are CLAP plugins that do scale properly in Reaper, for example LSP or Chowdhury DSP, so Reaper definitely does something right.

To summarize:
VST3 of Dragonfly Hall doesn't scale the contents at all in Reaper, but at least isn't cropped. It does scale properly in Bitwig.
CLAP of Dragonfly Hall scales the contents properly in Reaper, but the window is cropped. It does scale properly in Bitwig.
VST2 of Dragonfly Hall does everything correctly both in Reaper and Bitwig, but it uses the global scale as the scaling factor.

@pawelulita
Copy link
Author

pawelulita commented Feb 7, 2024

I also realised that Bitwig and Reaper take different paths in getSize() in DistrhoPluginCLAP.cpp:

  • For Bitwig, the branch in if (UIExporter* const ui = fUI.get()) gets executed and the function returns early.
  • For Reaper, this branch doesn't get executed. So, my attempt to fix the size at the bottom of the function doesn't affect Bitwig, but it does affect Reaper, because the function doesn't exit early.

It's as if Reaper and Bitwig wanted to get the initial size at different stages of plugin initialisation?

@falkTX
Copy link
Contributor

falkTX commented Feb 10, 2024

some hosts will ask for UI size before creating a window for it to embed into, others will first create the window and ask for UI size afterwards.
this leads to a few differences in behaviour yes, but we need to be able to cope with both cases.

your patch was helpful on finding the case where things are failing. when hosts requests the size early and plugin has macros defined for default size, dpf needs to have that initial size multiplied by the scale factor.
corrected as per ce3f6c1

give it a try and let me know if it works for you

@pawelulita
Copy link
Author

pawelulita commented Feb 12, 2024

Thanks for spending some time on it!

I've just compiled Dragonfly Reverb against the commit you linked above. It seems like the window size is fixed for CLAP in Reaper, but it doesn't affect VST3 (not scaled at all) and VST2 (scaled using a different scale).

Screenshot_20240212_173435

The CLAP version of d_info scales properly, but the rest doesn't.

Screenshot_20240212_181653

Dragonfly Reverb doesn't seem to be affected by these changes in Bitwig (i.e. all is good there, besides that VST2 uses a different scale).

Screenshot_20240212_193202

There's something strange with d_info, though, because the CLAP version has strange proportions. But I've just checked, and the current main (1504e7d) has the same problem. So it doesn't seem to be related to the changes you linked above.

Screenshot_20240212_192549

I tested this using:
Reaper 7.11 (200%)
Bitwig Studio 5.1.3 (Demo, 200%)
KDE Plasma 5.27.10 (Wayland, 175%)

@falkTX
Copy link
Contributor

falkTX commented Mar 8, 2024

can you check d_info against latest dpf develop please? somehow I did not have high-dpi handling for that example plugin in place yet, and was sure I did...
thanks

@pawelulita
Copy link
Author

This is what I'm getting using the latest develop, i.e. 4383c8e.

Reaper:
Screenshot_20240313_171815

Bitwig:
Screenshot_20240313_172153

So it seems like the contents are scaled properly now (assuming the different scale for VST2 is fine), but there are some problems with the size. Improvement! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants