Resize problems

[perlindgren]

Hi Thanks for the great work with linvst3.

I have encountered a number issues. It's hard to tell if they are due to linvst3, wine or the plugins per se.

The most obvious is regarding HDPI. It appears that window position will not take HDPI setting into account. E.g., if the plugin opens a new window (such as a dropdown menu) the positon will be wrong (as in not taking the scaling into account).

The second obvious thing is that resizing a plugin window will not take effect until the plugin window is closed and re-opened again.

In combination with a HDPI setting (else than the default), some plugins (Juce based if that is of any significance), can end up in a state where the wine window is smaller than the plugin window, with the effect that you cannot reach the resize handle. In that case the only option is to completely unload the vst (e.g. bitwig allows that), set the HDPI to 96, re-load the vst, and then regain control over the sizing handle.

I'm on arch linux and installed the linvst2 and linvst3 using the yay package manager.

I also encountered a problem with midi controller forwarding (not notes but controller data). It works well in linvst2 (with vst2 plugins) but in cases you can see (in bitwig) that the controller value changes (on the low bar) but the controller data is not forwarded/handled by the plugin. Not sure if that is due to a bug/incorrect implementation in the plugin, but this behaviour is not present if I run the same plugin in bitwig under Win10.

Thanks again for you efforts. /Per

[perlindgren]

Maybe I should also mention that I'm currently running wine-5.2 (installed by yay), not the wine-staging version.

[osxmidi]

I don't think I can do much about the window sizes as they are fixed by the plugin.

The CC data, as far as I know it does seem to work but I'll test it.

[osxmidi]

The reason for the manual close the UI and then open the UI again after a resize, is because the Linux Daw's don't handle vst resizing that well, so it's better to do it manually.

I tested CC7 Volume with the Sforzando VST3 and it seems to be ok.

[perlindgren]

Not sure I fully understand 1) you purposefully don't forward resizing events (to avoid problems with the DAW) 2) or you don't get re-sizing events (from the plugin through wine) 3) or in my case the bitwig host gets them but don't handle them Is it any of these alternatives or something else that happens?

Regarding CC, yes it seems to work with some plugins but not all (e.g. Stage Craft, Scratch Track).

Thanks for you input.

[osxmidi]

Not sure I fully understand

1. you purposefully don't forward resizing events (to avoid problems with the DAW)

2. or you don't get re-sizing events (from the plugin through wine)

3. or in my case the bitwig host gets them but don't handle them
   Is it any of these alternatives or something else that happens?

Regarding CC, yes it seems to work with some plugins but not all (e.g. Stage Craft, Scratch Track).

Thanks for you input.

It's a hassle trying to implement automatic resizing with the Linux Daws.

I've only succeeded with automatic resizing with Linux Reaper and that was too hacky and unreliable as far as I'm concerned, so it's just a case of closing and then reopening the UI for the new window size to take effect which is reliable.

As far as what's happening with JUCE vst3s, I don't know but I do know that JUCE's vst3 is not the most bug free thing around at the moment and they are improving it, and there is no native Linux JUCE vst3 either at the moment because of Linux Daw problems in the way native vst3's are handled and the way JUCE is designed.

Midi CC info gets sent to the plugin in the same way as the usual midi events do (note on note off etc), so I don't know why there would be problems.

[perlindgren]

Hi again. I did some progress.

Regarding midi CC (parameter automation). I got it working the problem was on my side I believe.

Next up:

1) was able to compile and install the latest linvst3 from source (using the latest vst3sdk). I saw there is this -DEMBEDRESIZE flag presumably to allow for resizing. I enabled that on both suggested location. It compiled.

So I now have the new:

-rwxr-xr-x  1 pln users    712 Feb 23 20:36 lin-vst3-servertrack.exe*
-rwxr-xr-x  1 pln users 536304 Feb 23 20:36 lin-vst3-servertrack.exe.so*
-rwxr-xr-x  1 pln users 103936 Feb 23 20:36 linvst3.so*

and I made a sudo make install

install -d /usr/bin
install -d ./vst
install -m 755 linvst3.so ./vst
install -m 755 lin-vst3-servertrack.exe lin-vst3-servertrack.exe.so /usr/bin

Some questions:

A) Do I need to re-run some the bridge creator, or? (I used w2lvst3 packed with the linvst (aur) previously). I prefer to run a command line tool instead of the GUI based converter.

I run BitWig as my DAW under Linux (not sure how it is supposed to handle re-size event, as I have seen no linux native vst3 that does re-scale).

What should I expect when having it compiled with the EMBEDRESIZE flag?

B) It seems that sizing of window re-opening does not take HDPI into account (neither under linvst nor linvst3). This has the effect that on higher HDPI parts of the VST GUI is not displayed/reachable, including the hook allowing the window to be re-sized. (The only option is to use it on the native 96DPI, but then on a 4k laptop the text becomes almost unreadable).

You wrote:

I don't think I can do much about the window sizes as they are fixed by the plugin.

That's strange, since it works under Win10 with different HDPI settings as far as I know. And indeed the (Scratch Track) plugin scales the graphics and text gets bigger, when I set a higher DPI using winecfg. So the problem might be either with Wine or the bridge.

[perlindgren]

Closed by mistake ...

[perlindgren]

Hmmm might be a Juce issue then:

https://forum.juce.com/t/high-dpi-issue-on-windows-with-vst3-plugins/37020

[perlindgren]

Looking at the Juce discussion, does linvst3 propagate those api calls (setContentScaleFactor, resizeHostWindow, setBounds )?

It seems that Juce tries to compensate for the DAW, and that BitWig (under Windows at least) should work correctly with Juce. (At least if Juce understands that it deals with a BitWig host).

How does a plugin know what host (DAW) it operates under, and does linvst3 propagate that mechanism?

And of course the question is if the linux version of BitWig handle HDPI plugins at all. I assume so, but I don't know any native linux vst3s that handles HDPI, so I've not been able to test it. In the uHe VSTs you can change UI size, but I guess it just amounts to having larger UI components rather than proper scaling, but I'm not sure.

[osxmidi]

I'll look into HDPI.

[perlindgren]

Have you had time to look deeper inte tho HDPI issue?