zyn-fusion-issues icon indicating copy to clipboard operation
zyn-fusion-issues copied to clipboard

LV2 plugin window can't be resized

Open Spunge opened this issue 5 years ago • 6 comments

LV2 has support for window resizing. Zyn has a beautifully scaling UI practically designed for a touch interface. I bought a 22 inch multi-touch screen after playing around with zynaddsubfx in standalone mode (which resizes perfectly) and boy oh boy did i have fun.

Now i would like to use zyn as a LV2 plugin, as zyn has no way to update control knob values on my midi controller when loading up patches (zyn does not do midi output), but synthpod can do this. Sadly, i discovered that zyn lv2 does not let me resize the x11 window, which makes using the UI via touchscreen a lot harder / less fun.

i know there's this: https://github.com/zynaddsubfx/zyn-fusion-issues/issues/185 and https://github.com/zynaddsubfx/zyn-fusion-issues/issues/57, which seem to be a lot of work.

This one however only requires removing ui:noUserResize from the lv2:optionalFeature in ZynAddSubFX_ui.ttl

Spunge avatar Jul 26 '19 13:07 Spunge

Seems there's more to it, zyn-fusion is passing fixed minimum & maximum window size hints to X11, making the window a fixed size in all hosts except carla (which seems to be ignoring size hints).

xwininfo output:

  Normal window size hints:                       
      Program supplied size: 1181 by 659          
      Program supplied minimum size: 1181 by 659  
      Program supplied maximum size: 1181 by 659  
  No zoom window size hints defined

Spunge avatar Jul 27 '19 13:07 Spunge

Looks to me like the Distrho UI is causing this here: https://github.com/falkTX/DPF/blob/master/distrho/src/DistrhoUIInternal.hpp#L160

Am i right?

Spunge avatar Jul 27 '19 14:07 Spunge

It is caused by DPF, though the exact where might have changed over time as DPF evolved. Looking at the current DPF master (as opposed to the used submodule version) it looks like Window::setGeometryConstrtaints might need to be called at some point to have the correct X11 window parameters https://github.com/DISTRHO/DPF/blob/master/dgl/Window.hpp#L112 That API is available in the more recent versions of DPF, though there shouldn't be any troubles updating.

The geometry specification might end up getting called in some way by setting the resizeing flag in the class that you've linked, though I'm not 100% sure.

I would have sworn the hosts that I was trying to use for LV2 operation allowed resizing, though they may have been ignoring invalid constraints set up by zyn.

fundamental avatar Jul 27 '19 14:07 fundamental

I would have sworn the hosts that I was trying to use for LV2 operation allowed resizing, though they may have been ignoring invalid constraints set up by zyn.

If you used carla to test, then yes, carla ignores x11 size hints. Ardour & synthpod respect size hints.

Spunge avatar Jul 27 '19 14:07 Spunge

It might have been carla and jalv based testing at the time, so it could have gotten by initially.

fundamental avatar Aug 12 '19 23:08 fundamental

I know this issue is specifically mentioning LV2 but the same issue affects VST.

u-he plugins provide interface options to resize their GUIs which work perfectly. I have two DAWs I use regularly: Renoise and Mixbus (Ardour).

In Renoise the plugin windows are not user resizeable by dragging on window edges but a plugin can still resize it's own window and so the u-he plugins resize as expected in response to the plugin's own resize options.

In Mixbus draggable window resizing is implemented but u-he plugins do not resize in response to this, you just get a bigger window with the interface drawn in the top left corner and black everywhere else. However, the normal u-he method of resizing by asking the plugin to resize itself still works perfectly.

Implementing a u-he-style system of preset GUI scales and self-management would solve this problem. I note that the Surge project has done exactly this with success.

AYANE-69 avatar Sep 04 '20 04:09 AYANE-69