Zoom issues with VST2/VST3 under linux REAPER

[mortfell]

From @Tobbe on the REAPER Linux forum, it seems VST2 is not zooming for him and VST3 zooms but gets clipped on the bottom.
Seems like issue #937 covers the VST2 resizing (this is something that can't really be fixed right now?) But VST3 problem is new as far as I can tell.

I have also noticed this graphical clipping from VST3 on one of the last couple updates in Linux but forgot to report it, to my memory it was working before but something changed it.

Here is his post:

Track 1 is VST3 and it almost hides Menu buttom and chops of the yellow/orange section (I'm colorblind so I don't see if it is yellow or orange).

Track 2 is VST2 and I can't resize it, but it doesn't hide Menu or the other thing in yellow section.

Both is on default size.

I loaded up Ardour and VST2 is working perfect as LV2 version. Can resize without any problems. VST3 doesn't popup, maybe it doesn't support VST3 yet.
I let him know VST3 is only really working well with REAPER so far

I had this version two days ago: Surge-linux-x64-NIGHTLY-2019-09-07-3df2128
And installed this one yesterday: Surge-linux-x64-NIGHTLY-2019-09-08-15701c8 and that is the current installed version

Here's some info on his computer (inxi -Fxz):
System: Host: homestudio Kernel: 5.0.0-27-lowlatency x86_64 bits: 64 compiler: gcc v: 7.4.0 Desktop: Xfce 4.12.3
Distro: Linux Mint 19.1 Tessa base: Ubuntu 18.04 bionic
Machine: Type: Desktop System: LENOVO product: AIO-520S-23IKU v: Lenovo Product serial:
Mobo: LENOVO model: SKYBAY v: 31900006 WIN 1801936976310 serial: UEFI [Legacy]: LENOVO v: O34KT23A
date: 03/14/2019
Battery: Device-1: hidpp_battery_0 model: Logitech Wireless Mouse M325 charge: 100% status: Discharging
CPU: Topology: Dual Core model: Intel Core i5-7200U bits: 64 type: MT MCP arch: Kaby Lake rev: 9 L2 cache: 3072 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 21696
Speed: 708 MHz min/max: 400/3100 MHz Core speeds (MHz): 1: 692 2: 700 3: 686 4: 700
Graphics: Device-1: Intel HD Graphics 620 vendor: Lenovo driver: i915 v: kernel bus ID: 00:02.0
Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa
resolution: 1920x108060Hz, 1920x108060Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 620 (Kaby Lake GT2) v: 4.5 Mesa 19.0.8 direct render: Yes
Audio: Device-1: Intel Sunrise Point-LP HD Audio vendor: Lenovo driver: snd_hda_intel v: kernel bus ID: 00:1f.3
Device-2: Texas Instruments PCM2902 Audio Codec type: USB driver: hid-generic,snd-usb-audio,usbhid bus ID: 1-1:2
Sound Server: ALSA v: k5.0.0-27-lowlatency
Network: Device-1: Intel Dual Band Wireless-AC 3165 Plus Bluetooth driver: iwlwifi v: kernel port: f040 bus ID: 01:00.0
IF: wlp1s0 state: down mac:
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Lenovo driver: r8169 v: kernel port: e000
bus ID: 02:00.0
IF: enp2s0 state: up speed: 1000 Mbps duplex: full mac:
Drives: Local Storage: total: 769.45 GiB used: 24.58 GiB (3.2%)
ID-1: /dev/sda vendor: SanDisk model: SD8SB8U256G1001 size: 238.47 GiB
ID-2: /dev/sdb type: USB vendor: Seagate model: ST9250410AS size: 232.89 GiB
ID-3: /dev/sdc type: USB vendor: Hitachi model: HTS723232A7A364 size: 298.09 GiB
Partition: ID-1: / size: 40.27 GiB used: 9.19 GiB (22.8%) fs: ext4 dev: /dev/sda2
ID-2: /boot size: 1.91 GiB used: 155.9 MiB (8.0%) fs: ext4 dev: /dev/sda1
ID-3: /home size: 191.25 GiB used: 15.24 GiB (8.0%) fs: ext4 dev: /dev/sda3
Sensors: System Temperatures: cpu: 53.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info: Processes: 212 Uptime: 5m Memory: 15.58 GiB used: 857.5 MiB (5.4%) Init: systemd runlevel: 5 Compilers: gcc: 7.4.0
Shell: bash v: 4.4.20 inxi: 3.0.27

[baconpaul]

Yeah the VST2 Repear Linux zoom just doesn’t work.

I saw that VST3 off-by-one the other day on linux too. I’ll tag this as 1.6.2 and look before we release.

[baconpaul]

Just notes to myself in case I stop. This doesn't occur on macOS VST3 Reaper.

[baconpaul]

And I can definitely reproduce it on linux.

[baconpaul]

It seems reaper on linux is eating 8 pixels of my paint area.

If I apply this (dumb non mergeable) patch the problem goes away

diff --git a/src/common/gui/SurgeGUIEditor.cpp b/src/common/gui/SurgeGUIEditor.cpp
index 98757b3..03155e0 100644
--- a/src/common/gui/SurgeGUIEditor.cpp
+++ b/src/common/gui/SurgeGUIEditor.cpp
@@ -120,8 +120,8 @@ SurgeGUIEditor::SurgeGUIEditor(void* effect, SurgeSynthesizer* synth, void* user
    rect.left = 0;
    rect.top = 0;
 #if TARGET_VST2 || TARGET_VST3   
-   rect.right = WINDOW_SIZE_X * zf;
-   rect.bottom = WINDOW_SIZE_Y * zf;
+   rect.right = WINDOW_SIZE_X * zf + 8;
+   rect.bottom = WINDOW_SIZE_Y * zf + 8;
 #else
    rect.right = WINDOW_SIZE_X;
    rect.bottom = WINDOW_SIZE_Y;
@@ -1443,7 +1443,7 @@ bool PLUGIN_API SurgeGUIEditor::open(void* parent, const PlatformType& platformT
 #if TARGET_VST2
    CRect wsize(0, 0, WINDOW_SIZE_X * fzf, WINDOW_SIZE_Y * fzf);
 #else
-   CRect wsize( 0, 0, WINDOW_SIZE_X, WINDOW_SIZE_Y );
+   CRect wsize( 0, 0, WINDOW_SIZE_X + 8, WINDOW_SIZE_Y + 8 );
 #endif
    
    CFrame *nframe = new CFrame(wsize, this);
diff --git a/src/vst3/SurgeVst3Processor.cpp b/src/vst3/SurgeVst3Processor.cpp
index c19e868..7a76ef7 100644
--- a/src/vst3/SurgeVst3Processor.cpp
+++ b/src/vst3/SurgeVst3Processor.cpp
@@ -760,8 +760,9 @@ void SurgeVst3Processor::setParameterAutomated(int inputParam, float value)
 void SurgeVst3Processor::handleZoom(SurgeGUIEditor *e)
 {
     float fzf = e->getZoomFactor() / 100.0;
-    int newW = WINDOW_SIZE_X * fzf;
-    int newH = WINDOW_SIZE_Y * fzf;
+
+    int newW = WINDOW_SIZE_X * fzf + 8;
+    int newH = WINDOW_SIZE_Y * fzf + 8;

[baconpaul]

Ugh
I feel like this is a reaper linux bug
I may for now hack in that +8
but if they fix it then it will mispaint
any ideas on how to reach the reaper devs?

[baconpaul]

OK so here's my thinking

1. Can we get in touch with team reaper?
2. If not I can figure out if the host is reaper and we are linux vst3 and put that +8 through with a switch where we could disable it
3. I like plan 1 better

[baconpaul]

Another thing we could do is, if 1 is slow, release 1.6.2 with this bug and ship a 1.6.2.1 when we find the solution.

[mortfell]

Yeah it doesn't happen on Windows VST3 either.

I'm not sure about getting in touch with the REAPER devs, they definitely take feedback from the community a lot and update REAPER with bug fixes all the time. But there is a TON of feature requests and things all the time.

If it's a bug that's something they would look at faster. @mkruselj has been involved with that community for a long time, maybe he would have some thoughts on that.

I feel like this issue with the VST3 was not an issue when I first installed the Surge nightly a week on Linux a week ago though..... but maybe I'm wrong? Is there backups of the nightly's somewhere?

[baconpaul]

https://forum.cockos.com/showthread.php?p=2180198#post2180198

[baconpaul]

So nothing from the Reaper team on this. I think we will push forward with 1.6.2 with this linux clipping in place on the VST3. I'm going to classify this out of the release.

[justinfrankel]

It appears your IPlugView::canResize() returns kResultTrue, meaning that the plug-in supports variable sizing. In this case, implementing IPlugView::checkSizeConstraint() would probably help?

[sub26nico]

Resizing now works (tested with the vst3) but the issue at the bottom (pixels missing) is still there.

[baconpaul]

@justinfrankel thanks for the pointer - I will try that this week. Any idea why the linux reaper deals differently than the mac and windows reaper though? The 8 pixel clip is what’s really getting me confused. (I actually send the size messages out of my VST3 using the IPlugView API when users do resize on the zoom menu).

[baconpaul]

Alright here's what's happening

I put print statements in the place where I call IPlugFrame::resizeView and also where I get called back in IPlugFrame:nSize and IPlugFrame::checkSizeConstraint (which I have now implemented).

On macOS I get the following when I resize (which I do by doing "menu/zoom/zoom to 125%" in this case:

Asking to resize to 1130 677
checkSizeConstraint 0 1130 1130x677
onSize 0 1130 1130x677

whereas on Linux I get this

Asking to resize to 1130 677
checkSizeConstraint 0 1122 1122x669
onSize 0 1122 1122x669

so yeah, for some reason you are just taking 8 pixels away from my desired size. But only in Reaper. And only on Linux.

So I guess I could code defensively around this. looks like in checksizeconstraint I can overrule you to tell you the size I want, after I told you the size I want

Is that the right solution? Why does only linux and only reaper do this in the VST3? Before I write that bit of code (which is a bit painful of course because the size I requested is not handed to me just the size you want to give me), I want to make sure this is what you intended Reaper/Linux to do.

Thanks

[justinfrankel]

Thanks, let me see why this is happening on our end.

[baconpaul]

Cool
If I implement checkSizeConstraint and whack the rectangle to the size I requested, everything does work. So I do have a workaround.

Basically checkSizeConstraint is a noop for every other host but on reaper it will add my pixels back :)

So I have a fix (yay!! thank you!) but before I push it I want to make sure you want me to!

Thanks for the help.

[baconpaul]

Oh and if you are building the synth, the master branch has the bug and the 'reaper-log' branch at the baconpaul fork has it fixed with the workaround.

[justinfrankel]

Thanks -- I've figured out the problem on our end, fixing it now!

[baconpaul]

Awesome!!

[justinfrankel]

The latest REAPER development build (see our pre-release forum) should fix this issue. Thanks again!

[sub26nico]

The latest REAPER development build (see our pre-release forum) should fix this issue. Thanks again!

Just tried it and no more issue. Thanks a lot @baconpaul and @justinfrankel

[baconpaul]

Great! Thanks @justinfrankel !! Closing this issue.