zynaddsubfx / zyn-fusion-issues

Issue Only Repo
31 stars 0 forks source link

LV2 plugin window can't be resized #226

Open Spunge opened 5 years ago

Spunge commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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?

fundamental commented 5 years ago

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.

Spunge commented 5 years ago

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.

fundamental commented 5 years ago

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

AYANE-69 commented 4 years ago

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.