search

osxmidi / LinVst

Linux Windows vst wrapper/bridge
GNU General Public License v3.0
674 stars 41 forks source link

LinVst master - resize feedback #166

Closed keybreak closed 3 years ago

keybreak commented 3 years ago

New resize functions works really good under this conditions:

However there are some problems when using resize handler on bottom right window, which is one of the most common methods this days it seems...

Problem is that when mouse goes out of window (and obviously it will since it's on edge) resize either stops or mouse stucks in resize mode - so it's really hard to resize such windows now.

I can't consider this a regression, since it's a huge progress overall, however...perhaps you would have some ideas how to reduce that effect with edge handle resize.

Tested with Renoise v3.2.2

Enviroments

OS: Manjaro 20.1.2 Mikah
Kernel: x86_64 Linux 5.8.16-2-MANJARO
Shell: bash 5.0.18
DE: KDE 5.74.0 / Plasma 5.19.5
WM: kwin_x11 
dm: SDDM 
gcc: 10.2.0 
tk: Qt 5.15.1
driver: nvidia v: 455.28 
WINE: 5.19-staging amd64

VST

Developer Name Version Arch
Unfiltered audio Byome v2.0 x64

VSTi

Developer Name Version Arch
Madrona labs Aalto v1.8.5 x64
Stanton Deckadance 2.72 x32
keybreak commented 3 years ago

I'm just speculating in thought, but maybe it's possible to temporarily bypass and debounce function which live-captures window focus, while receiving window resize calls?

Resize event is pretty rare anyway :upside_down_face:

osxmidi commented 3 years ago

Resizing is a bit of a problem.

Different Daws can do different things and then there are the problems of dealing with Wine and X11 Windows when a resize event happens.

The easiest way is to resize the window and then close and reopen the window.

The problem you talk about with dragging a corner of the window to a new size, is a problem because the plugin generates multiple resize events one after another while the window is being resized and then every resize needs a X11 window update which might cause choppy resizing (not smooth) and then there is the mouse edge problem which is basically controlled by Wine.

Maybe there is a way to do it, but it's not a high priority at the moment.

keybreak commented 3 years ago

Sure, let's just put a mental paperclip here then :smile:

The easiest way is to resize the window and then close and reopen the window.

That implies either to turn off auto-resize feature (which is really cool in a lot of cases) or turn off auto-focus grab, otherwise it's extremely hard to resize in a first place, before closing window (the only way is to use very low mouse cursor speed and move slowly) :thinking:

P.S. Oh you made complete rollback

keybreak commented 3 years ago

But the core idea with auto-resize is very good (i think despite of the one problem mentioned overall it's better than not having it)

If it won't affect other issues maybe it's a good idea to add the codebase for it and switch with build-flag (maybe not on by default), once all the dust with rollback settles :smiley:

osxmidi commented 3 years ago

But the core idea with auto-resize is very good (i think despite of the one problem mentioned overall it's better than not having it)

If it won't affect other issues maybe it's a good idea to add the codebase for it and switch with build-flag (maybe not on by default), once all the dust with rollback settles

Yes, I'll try to redesign the resize code and turn off the focus etc and then I'll add it later on.

osxmidi commented 3 years ago

I've changed the resize code, and the drag corner window resizing seems to work with the Valhalla Delay plugin I used for testing.

If you want to test it out try the Makefiles in the Resize folder.

keybreak commented 3 years ago

Thx, i'll certainly test it soon!

keybreak commented 3 years ago

Tested about 20 different plugins all seems to behave perfectly in all cases!

Few minor stuff like:

  1. Some plugins like Unfiltered audio Byome / Madrona labs Aalto look a little stutter'y during resizing, but i doubt there's anything you can do about it, looks like it's Wine slow to redraw some GUIs, and it's rare.

  2. Some plugins sometimes Voxengo Gliss EQ for example, if you position them to something like top/left of screen or right/bottom might reset their position to some weird position (for example like center of the screen), during handler resize, but it's still usable and resizeable

Overall my verdict for now it's safe to use as default (at least on Renoise), maybe if you could think of what caused 2nd minor problem i'd test again though :upside_down_face:

keybreak commented 3 years ago

According to latest master updates should be safe to remove Resize dir now

osxmidi commented 3 years ago

Resizing seems to work ok, I can't duplicate the GlissEQ thing on my system. I might get around to removing the resize folder, I might just leave it there for the time being.

keybreak commented 3 years ago

Check this out, we're not alone here:

PSPaudioware plugins with expandable GUIs, such as E27, may have their GUI appear in the wrong location after the GUI has been expanded. You can enable an alternative editor hosting mode to fix this.

(c) https://github.com/robbert-vdh/yabridge

btw, very well documented project, that was exactly what i had in mind to propose, like that: https://github.com/robbert-vdh/yabridge/commit/016ceccc180dec5267e1052961ffe99fa9a76124

There are a lot of stuff we've uncovered like that and song-saving which should be marked to never change, otherwise there will be a lot of problems :smile:

osxmidi commented 3 years ago

Check this out, we're not alone here:

PSPaudioware plugins with expandable GUIs, such as E27, may have their GUI appear in the wrong location after the GUI has been expanded. You can enable an alternative editor hosting mode to fix this.

(c) https://github.com/robbert-vdh/yabridge

btw, very well documented project, that was exactly what i had in mind to propose, like that: robbert-vdh/yabridge@016cecc

There are a lot of stuff we've uncovered like that and song-saving which should be marked to never change, otherwise there will be a lot of problems

Yes, all windows GUI routines have to be on the main thread.

I'm not going to change any threads, so it should be ok.

robbert-vdh commented 3 years ago

@keybreak Since that commit I settled on basically only handling those few opcodes form the main GUI thread, and handling all other function calls from the calling thread. That's quite significantly improved performance in yabridge since basically every dispatch() and audioMaster() call can now be handled concurrently, and I have not found any issues after having tested about 400 plugins in four different hosts.

keybreak commented 3 years ago

@robbert-vdh Wow, that's heavy testing, i've done ~2000 with Renoise / LinVst here: https://keybreak.github.io/linux-vst-compatibility-list/ https://github.com/keybreak/linux-vst-compatibility-list

Once i'll be confident enough with whole scheme and add user list, i'll make sure to mention you so we can join our testing efforts :wink:

@osxmidi I know...but i'm a little paranoid about not documenting breaking stuff, i'll get back on that later

robbert-vdh commented 3 years ago

@keybreak I've been on that page before haha, but wow that's still an impressive list! With yabridge I've deliberately not kept track of what does and what does not work since, by yabridge's design, if anything doesn't work then that's usually an issue with Wine and it should be reported on Wine's bug tracker, although I do keep a list with some common issues and solutions for things like the d2d1 stuff. So far that's been working out very well, but yeah I guess it'd still useful to have a more searchable alternative to Wine's AppDB for VST plugins!

keybreak commented 3 years ago

@robbert-vdh Technically i agree with your approach (and personally i do kinda that), but i thought it really makes sense to make that way for few reasons:

So it's kinda paranoid AppDB base i guess, for people who really want their stuff to be stable in studios etc!

Hopefully someone really good with reverse-engineering skills will step in for proper d2d1 and that MVC ongoing effort:

NOTE: There is an ongoing effort in Wine to provide a complete Microsoft Visual C++runtime library replacement - removing the need of installing the Microsoft VC++ redistributables packages. This is a work in progress hence you might still need to install Microsoft VC++ runtime.

https://appdb.winehq.org/objectManager.php?sClass=application&iId=5766

btw, maybe you guys know where can one monitor progress on MVC replacement effort? Wine is a freaking maze.

Those two would heal absolute most of problems :smile:

P.S. Oh and btw also maybe Wine devs would see by clicking filtering by errors and d2d1, how many d2d1 plugins are actually affected currently and there is real demand for proper dll (personally i use those) :partying_face: Usually people mention just couple obvious ones on Wine's bugtracker, like Serum etc :upside_down_face: