-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Comments
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. |
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: |
I also realised that Bitwig and Reaper take different paths in
It's as if Reaper and Bitwig wanted to get the initial size at different stages of plugin initialisation? |
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. 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. give it a try and let me know if it works for you |
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). The CLAP version of 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). There's something strange with I tested this using: |
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... |
This is what I'm getting using the latest 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! 🎉 |
This is related to michaelwillis/dragonfly-reverb#151.
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.
The text was updated successfully, but these errors were encountered: