VST3 version of XT too large and unresizable in Ardour on Fedora with 200% scaling

[dieggsy]

Bug Description:

XT VST3 plugin not resizable in Ardour on Fedora 35 (Gnome). The default is too large on a 2k display with 200% scaling in Gnome, and the GUI cannot be resized with either corner dragging or Menu -> Zoom ...

Surge Version

• Version: Surge XT 0.99.main.bc53d94
• Plugin Type: VST3
• Bitness: 64-bit

Reproduction Steps:
Steps to reproduce the behavior:

1. Install the Fedora release RPM using the workaround here: https://github.com/surge-synthesizer/releases-xt/issues/3
2. Open the VST3 plugin in Ardour
3. Attempt to resize the window
4. Window is too large and not resizable.

Expected Behavior:
Window starts at more reasonable size and/or is at least resizable.

Screenshots:
Defaults to 175% Zoom, not changeable:

Computer Information (please complete the following information):

• OS: Fedora 35
• Host: Ardour
• Version: 6

Additional Information:
Note that the RPM is unusable as is until this issue is addressed: https://github.com/surge-synthesizer/releases-xt/issues/3

[baconpaul]

Did you try resizing with the zoom menu and does that work? I think ardour has a problem with vst3 drag to resize.

[dieggsy]

The zoom menu also does not work. The VST3 for 1.9 was rezisable with either method I believe, so I'm not sure if ardour is the cause here.

[mkruselj]

Suspicious, if zooming works perfectly fine in any other DAW...

[baconpaul]

Yeah lots of moving parts - I’ll try and get ardour on ubuntu running but would be good to know if @selenologist can zoom vst3 ardour arch to eliminate moving parts

[selenologist]

I can confirm zoom works fine from the menu (didn't try dragging the borders) on
Version: Surge XT 0.9.main.57932618
Build: 2021-11-12 @ 23:56:41 on '[hostname redacted]' with 'GNU-11.1.0' using JUCE 60102
System: Linux 64-bit VST3 on AMD Ryzen 7 2700X Eight-Core Processor
Host: Ardour

However, after copying the latest surge from git in to test that, Ardour locks up during startup. Connecting gdb to the process, it seems we hang in setStateInformation.

(gdb) back
#0  0x00007f4bfaaf34a5 in SurgeSynthProcessor::setStateInformation(void const*, int) () at /home/luna/.vst3/Surge XT.vst3/Contents/x86_64-linux/Surge XT.so
#1  0x00007f4bfaaf3072 in juce::JuceVST3Component::setState(Steinberg::IBStream*) () at /home/luna/.vst3/Surge XT.vst3/Contents/x86_64-linux/Surge XT.so
#2  0x00007f4d1ea65016 in Steinberg::VST3PI::load_state(Steinberg::RAMStream&) (this=0x558e31d6e740, stream=...) at ../libs/ardour/vst3_plugin.cc:2285
#3  0x00007f4d1ea640bd in ARDOUR::VST3Plugin::set_state(XMLNode const&, int) (this=0x558e32e31510, node=..., version=6000)
    at ../libs/ardour/vst3_plugin.cc:564
#4  0x00007f4d1e80e659 in ARDOUR::PluginInsert::set_state(XMLNode const&, int) (this=0x558e31cb25f0, node=..., version=6000)
    at ../libs/ardour/plugin_insert.cc:2818
#5  0x00007f4d1e8c3e81 in ARDOUR::Route::set_processor_state(XMLNode const&, int, XMLProperty const*, std::__cxx11::list<boost::shared_ptr<ARDOUR::Processor>,
std::allocator<boost::shared_ptr<ARDOUR::Processor> > >&, bool&)
    (this=<optimized out>, node=..., version=<optimized out>, prop=<optimized out>, new_order=<optimized out>, must_configure=<optimized out>)

...but that's another issue, sorry for the clutter. Just explaining why I'm out of date.

Note that I compile Ardour from git, and use the ardour6 binary that results. If you are able, you may want to try that @dieggsy and see if you get the same result :)

[selenologist]

Following baconpaul reverting the change that unfortunately caused an infinite loop on Ardour, I can confirm both the zoom menu and dragging the window borders works on:
Version: Surge XT 0.99.main.8775f736
Build: 2021-12-03 @ 23:32:18 on '[hostname redacted]' with 'GNU-11.1.0' using JUCE 6.1.2
System: Linux 64-bit VST3 on AMD Ryzen 7 2700X Eight-Core Processor
Host: Ardour @ 48.0 kHz

My ardour version is 8775f736, commit e1b2a24221143728d7f78922be0af8f1663edd9a

[baconpaul]

Thanks Luna!

[mkruselj]

@baconpaul sooooo is this one good to close then?

[baconpaul]

I don’t think there’s anything to be done but would be nice to know @dieggsy ardour version to figure out why it works for Luna and not them. I’ll tag it as probably bounce though

[mkruselj]

@dieggsy Care to provide some more info here, so that we know if we're closing this issue or not? Since we have Luna confirming it works fine in Ardour.

[mkruselj]

@baconpaul Considering OP is not replying I'm bouncing this to 1.1 for the time being.

[dieggsy]

Sorry for being awol:

Surge version: 9.NIGHTLY.2021.12.01.bc53d94
Linux info: Fedora 35 with Gnome 40 (wayland)
Ardour version: 6.9.0

@selenologist are you using the same DE as me (gnome wayland)? I'm wondering if that's the issue here. I can try compiling ardour from git, but probably not in the next week or so

[selenologist]

@selenologist are you using the same DE as me (gnome wayland)? I'm wondering if that's the issue here. I can try compiling ardour from git, but probably not in the next week or so

I am using i3wm under X11. It's possible this makes the difference, but would still recommend trying Ardour from git.

[keithzg]

Having the same too-large and unresizeable problems on Kubuntu 21.10 using the latest stable Surge deb (1.0.1.60228e8) and Ardour 6.9.0. As I'm using the default Kubuntu DE (Plasma) and I'm even on X11 on this machine still too, so the problem isn't specific to Gnome atop Wayland.

I have a 2160p monitor and my DE's scaling is set to 125%, and I know for years GTK/Gnome stuff didn't have fractional scaling factors like that so I do wonder if that's somehow part of that (since I'm reminded whenever I open a file picker dialogue that Ardour is a GTK application!) but that's just wild speculation on my part. I mostly just wanted to chime in and mention that the problem is reproduceable on a different desktop environment and display server.

Currently working around it by setting Ardour's scaling to as low as I can go without having to lean into my monitor too much, which resizes Surge XT down enough that I can actually see and use all of it at least.

[H3cJP]

I'm having exactly the same issue, happens exactly the same doesnt matter if wayland or xorg, i tried on my debian VM using KDE Wayland and XFCE4 (therefore xorg)
but im thinking, wouldnt be a better option to report this bug to ardour? it seems to be a problem not with surgeXT, i saw people having similar problems with other plugins like Helm on ardour

[baconpaul]

Sure!

[mkruselj]

Definitely sounds like something between JUCE and Ardour, or some of the libraries Ardour uses.

@baconpaul Should we close this one then?

[baconpaul]

It could also be ardour using the vst3 scaling api differently than other hosts

Would like to confirm that the same system doesn't do it with bitwig or reaper or some such but I'm not sure what a fix would be here other than if ardour somewhere in our zoom code