Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER for Linux

Reply
 
Thread Tools Display Modes
Old 01-19-2021, 07:36 AM   #1
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default Looking for testers for yabridge 3.x's upcoming VST3 support

EDIT 2: Thanks so much for all the help! Yabridge 3.0.0 has now been released, and thanks to the help from the REAPER community I've been able to track down a few subtle but quite important bugs in the implementation. Aside from VST3 support yabridge 3.0.0 also includes a lot of other improvements, fixes, and new features, so I encourage you to read the full changelog if you're interested to learn more: https://github.com/robbert-vdh/yabridge/releases

Original post below:


Hi,

I develop yabridge, and for the past few months I've been working hard to bring the first ever true Linux VST3 <-> Windows VST3 Wine plugin bridging to Linux. There's still lots of work to be done both in terms of testing and final polish, but all VST 3.7.1 features have been implemented and everything seems to work exactly like you'd expect it to work. REAPER's a bit specific about how some (GUI related) things should work in its VST3 implementation, and over the past few days I've been reworking some things to make sure everything works absolutely perfectly in REAPER. While everything seems to work great now for me and for some other people from the yabridge Discord who have also been testing it, I would very much appreciate some additional testing at this point.

Aside from VST3 support there have also been a substantial amount of other changes on the master branch. You can find the full in-progress changelog here: https://github.com/robbert-vdh/yabri...r/CHANGELOG.md

If anyone wants to help me out, then you can either install the yabridge-git and yabridgectl-git AUR packages if you're on Arch/Manjaro, or you can grab the latest yabridge and yabridgectl builds from the CI here. After installing or downloading those just follow the usual instructions from the readme. Because of the VST3 changes you'll need to use an up to date version of yabridgectl, and don't forget to rerun `yabridgectl sync` after upgrading yabridge.

Thanks a lot!

EDIT: Someone pointed out to me projects with VST3 plugins saved on Windows would not load with yabridge under Linux, and as it turns out there was an issue with mismatching VST3 plugin IDs. This has been fixed as of 2020-01-22, but this sadly did require a backwards incompatible change. I've written migration scripts that can update REAPER, Ardour, Bitwig and Renoise project files to account for these changes. You can find them along with instructions on how to use them here: https://github.com/robbert-vdh/yabri...ools/migration Sorry for this major inconvenience, but I'm very glad that we at least learnt of this before an actual release.

Last edited by robbert-vdh; 02-14-2021 at 07:47 AM. Reason: yabridge 3.0.0 has now been released.
robbert-vdh is offline   Reply With Quote
Old 01-20-2021, 06:57 AM   #2
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

GREAT STUFF !

I'm not very qualified for testing right now.

But I'd like to state that I am very happy top see such things happen. Using commercial plugins in a Linux DAW IMHO is absolutely mission critical.

In the end such a Bridge should be seamlessly integrated in the DAW. In Reaper maybe it can an "extension" and hence work invisible to the end user, low CPU overhead and still stay "3rd party".

Could you explain the difference vs the commonly use LinVST tool ?
A question that I have in mind long since: As Mac OS is based on BSD Linux and hence UNIX, it should be more similar to Linux than Windows. So why them Windows Plugins are the target for such bridging tools and not Mac plugins ?

-Michael
mschnell is offline   Reply With Quote
Old 01-20-2021, 08:27 AM   #3
Glennbo
Human being with feelings
 
Glennbo's Avatar
 
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,055
Default

Quote:
Originally Posted by mschnell View Post
In the end such a Bridge should be seamlessly integrated in the DAW. In Reaper maybe it can an "extension" and hence work invisible to the end user, low CPU overhead and still stay "3rd party".
Bridges don't really integrate into the DAW (with the exception of the developer including one), they make Windows VST plugins smell like Linux VST plugins to any Linux app that looks for Linux VST plugins.

Quote:
Could you explain the difference vs the commonly use LinVST tool ?
Looks to be the VST3 compatibility. I only have a few Windows plugins remaining which are all VST2. I quit buying Windows plugins a couple of years ago and have bought all native Linux plugins for all my audio VSTs.

There are others here though who are constantly installing Windows plugs so there should be both some demand for a VST3 bridge and some folks to test one.
__________________
Glennbo
Hear My Music - Click Me!!!
--
Glennbo is offline   Reply With Quote
Old 01-20-2021, 08:33 AM   #4
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by mschnell View Post
GREAT STUFF !

I'm not very qualified for testing right now.

But I'd like to state that I am very happy top see such things happen. Using commercial plugins in a Linux DAW IMHO is absolutely mission critical.

In the end such a Bridge should be seamlessly integrated in the DAW. In Reaper maybe it can an "extension" and hence work invisible to the end user, low CPU overhead and still stay "3rd party".

Could you explain the difference vs the commonly use LinVST tool ?
A question that I have in mind long since: As Mac OS is based on BSD Linux and hence UNIX, it should be more similar to Linux than Windows. So why them Windows Plugins are the target for such bridging tools and not Mac plugins ?

-Michael
Hi Michael,

First, as to why we can use Windows plugins on Linux but not do the same thing with macOS software. There's just not as much interest for it. Wine more or less does two things: it translates PE32(+) binaries into ELF so they can run under Linux, and it provides a reimplementation of the Windows system libraries so those applications can actually do things. There's no technical reason why we cannot do the same thing for macOS applications, but like Wine it would be a huge development undertaking and there's just not enough demand or interest for it to make it happen. Darling is more or less the Wine equivalent for macOS applications, but because of the lack of developer interest it still is unable to run more than very simple command line applications.

Next regarding yabridge versus other plugin bridges (with a bit of unnecessary background information, sorry haha). I've started using Linux full time back in 2016. The two things I kept Windows around for until that time were gaming and music production. Around that time Wine development really sped up, and I could finally run most of my games under Linux. And thanks to Bitwig, Airwave and LinVst I could also completely move over to Linux for music production. I've used LinVst (with a bit of Airwave before that) since then and I'm very glad they existed, but the experience has never been great. I took it as par for the course (because hey, using Windows plugins on Linux is a great feat in its own right), but there have always been crashes, freezes, lots of missing or weirdly implemented VST2.4 features (including basic things like note labels and resizing editor GUIs), plugins that somehow don't work under one host but then do work under others, and just general slowness and instability. I felt like it didn't have to be that way, so last year when the pandemic hit I finally decided that it was time to give back to the community and to try and fix all of the issues I had with LinVst. I started with a private fork with the intention to first clean up the project, get rid of all dead and hacky code, and to modernize the project before fixing those issues issues I was having and upstreaming the changes. When I was working on this however I very quickly realized that most of the issues I wanted to fix were fundamental, and would not be solvable in a clean way without a full rewrite. So instead I set out to write the best, most feature complete, transparent and user friendly VST2 plugin bridging experience I could. The main idea here was to do a complete one-to-one passthrough of all function calls made by the host and the plugin, with no deviation from that allowed. Yabridge is also able to concurrently handle multiple (mutually recursive) function calls. These two things has lead to yabridge having perfect host and plugin compatibility (assuming the plugin can run under Wine) without requiring hacks or host-specific workarounds for situations that other VST bridges cannot handle.

Now with yabridge 3.0 I'm looking to tackle another obstacle. So far there have not been any ways to use Windows VST3 plugins on Linux as if they were native VST3 plugins. There have been a few ways to use those plugins on Linux, but all of those methods involve wrappers and you lose out on the benefits of using VST3 plugins in the first place since you cannot use VST3 features that do not have a VST2 equivalent and you cannot benefit from the lower processing overhead VST3 plugins would have. So for the past few months I've been working hard on making this a reality, and at this stage every VST 3.7.1 feature has been implemented in yabridge's master branch and should in theory work, hence why I'm looking for other people to test some plugins and to report their findings.

Please let me know if you have any other questions!

Cheers,

Robbert
robbert-vdh is offline   Reply With Quote
Old 01-20-2021, 02:46 PM   #5
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

This sounds really great and it would be fantastic if those who use LinVST would give yabridge a try and report back.

I understand that you need to do some setup for any windows plugin you intend to use to allow loading in via LinVST. I suppose the same is the case with yabridge.

In a perfect world the loading of Windows VSTs would be transparent to the Reaper user: just the same process as with native Linux VSTs or like ith Windows VSTs in Reaper on Windows. Do you thinks something like that can be done by a Teaper extension ? (I doubt that and so the help pf the Reaper devs will be necessary.

I understand that usoing LinVST& or yabridge needs a full Wine installation. Is this really necessary ? Would it be viable to somehow integrate or "associate" just the necessary parts ow Wine with yaBridge ? (Maybe this does not make much sense as installing the full Wine does not do any harm at all.)

Thanks for listening.

BTW.: I suppose you already did test this but just in case these are the mission critical VSTs I use and supposedly are not available as native Linux versions:
- Kontakt by NI (VST2i) (here of course the licensing by Native Access needs to be working, as well)
- SWAM by Audio Modeling (VST2i) (unknown licensing scheme)
- Equator by Roli (VST3i) (unknown licensing scheme)
- VB3 by GSI (VST3i)
- Dexed free by Digital Suburban (VST3i) [E dit: there is a Linux (LV2) version of Dexed ]
- Guitar Rig by NI (VST2) (here of course the licensing by Native Access needs to be working, as well)
- SPAN by Voxengo (VST3)
- SPACE360 free by CytoSonic (VST2) This is a 32 But VST and needs to be run by the 32 Bit bridge provided by Reaper)

-Michael

Last edited by mschnell; 01-21-2021 at 11:48 AM.
mschnell is offline   Reply With Quote
Old 01-20-2021, 03:09 PM   #6
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by mschnell View Post
This sounds really great and it would be fantastic if those who use LinVST would give yabridge a try and report back.

I understand that you need to do some setup for any windows plugin you intend to use to allow loading in via LinVST. I suppose the same is the case with yabridge.

In a perfect world the loading of Windows VSTs would be transparent to the Reaper user: just the same process as with native Linux VSTs or like ith Windows VSTs in Reaper on Windows. Do you thinks something like that can be done by a Teaper extension ? (I doubt that and so the help pf the Reaper devs will be necessary.

I understand that usoing LinVST& or yabridge needs a full Wine installation. Is this really necessary ? Would it be viable to somehow integrate or "associate" just the necessary parts ow Wine with yaBridge ? (Maybe this does not make much sense as installing the full Wine does not do any harm at all.)

Thanks for listening.

-Michael
You indeed need some way to set up yabridge for your plugins. For yabridge I settled on having yabridgectl be the officially supported way to use yabridge. Basically you just tell yabridgectl where it can find your Windows VST2 and VST3 plugins and you then run `yabridgectl sync` to install and/or update yabridge for all of your plugins at once. Yabridgectl will then do all the rest with respect to searching for plugins, detecting leftover files, and making sure that yabridge will work correctly on your system before you even try to load a bridged plugin in your DAW.

In theory DAWs could integrate similar functionality, but without even considering the licensing aspects the main deal breaker here would be support. While I've worked directly with DAW developers to fix bugs in their DAWs that were affecting yabridge (and likely other plugins that happened to do similar things), none of those DAWs would ever officially support bridged plugins and for good reason. While everything works fine 99% of the time, you would still need to provide official support for it. And when using plugins through Wine there are a lot of variables to account for, too many to expect the DAW manufacturer to provide support for it. For REAPER a third party implementation of this might be possible (I'm not familiar enough with REAPER and its extension mechanism to say for sure), but in the end there would be very little appreciable difference in user experience over running `yabridgectl sync` every time you install a new plugin or update yabridge.

And integrating Wine into a plugin bridge itself would not make much sense in my opinion. You'd still need a regular Wine prefix to install your plugins and software to, and you'd a normal Wine installation to do so. So then you'd end up mixing multiple versions of Wine without any real benefit while also making it harder to upgrade the Wine version used for the plugin bridge (since never version of Wine often increase performance or application compatibility). Using a regular Wine installation installed through your system's package manager really is the way to go here.
robbert-vdh is offline   Reply With Quote
Old 01-20-2021, 03:54 PM   #7
Fergler
Human being with feelings
 
Fergler's Avatar
 
Join Date: Jan 2014
Posts: 5,207
Default

Thanks for the aur packages! I was a bit turned off of building myself since I'm only used to cmake and I'm a linux newb. Manjaro user.

I'll test what I can
Fergler is offline   Reply With Quote
Old 01-20-2021, 08:52 PM   #8
osxmidi
Human being with feelings
 
Join Date: Feb 2014
Posts: 620
Default

Quote:
Originally Posted by robbert-vdh View Post
Hi Michael,

First, as to why we can use Windows plugins on Linux but not do the same thing with macOS software. There's just not as much interest for it. Wine more or less does two things: it translates PE32(+) binaries into ELF so they can run under Linux, and it provides a reimplementation of the Windows system libraries so those applications can actually do things. There's no technical reason why we cannot do the same thing for macOS applications, but like Wine it would be a huge development undertaking and there's just not enough demand or interest for it to make it happen. Darling is more or less the Wine equivalent for macOS applications, but because of the lack of developer interest it still is unable to run more than very simple command line applications.

Next regarding yabridge versus other plugin bridges (with a bit of unnecessary background information, sorry haha). I've started using Linux full time back in 2016. The two things I kept Windows around for until that time were gaming and music production. Around that time Wine development really sped up, and I could finally run most of my games under Linux. And thanks to Bitwig, Airwave and LinVst I could also completely move over to Linux for music production. I've used LinVst (with a bit of Airwave before that) since then and I'm very glad they existed, but the experience has never been great. I took it as par for the course (because hey, using Windows plugins on Linux is a great feat in its own right), but there have always been crashes, freezes, lots of missing or weirdly implemented VST2.4 features (including basic things like note labels and resizing editor GUIs), plugins that somehow don't work under one host but then do work under others, and just general slowness and instability. I felt like it didn't have to be that way, so last year when the pandemic hit I finally decided that it was time to give back to the community and to try and fix all of the issues I had with LinVst. I started with a private fork with the intention to first clean up the project, get rid of all dead and hacky code, and to modernize the project before fixing those issues issues I was having and upstreaming the changes. When I was working on this however I very quickly realized that most of the issues I wanted to fix were fundamental, and would not be solvable in a clean way without a full rewrite. So instead I set out to write the best, most feature complete, transparent and user friendly VST2 plugin bridging experience I could. The main idea here was to do a complete one-to-one passthrough of all function calls made by the host and the plugin, with no deviation from that allowed. Yabridge is also able to concurrently handle multiple (mutually recursive) function calls. These two things has lead to yabridge having perfect host and plugin compatibility (assuming the plugin can run under Wine) without requiring hacks or host-specific workarounds for situations that other VST bridges cannot handle.

Now with yabridge 3.0 I'm looking to tackle another obstacle. So far there have not been any ways to use Windows VST3 plugins on Linux as if they were native VST3 plugins. There have been a few ways to use those plugins on Linux, but all of those methods involve wrappers and you lose out on the benefits of using VST3 plugins in the first place since you cannot use VST3 features that do not have a VST2 equivalent and you cannot benefit from the lower processing overhead VST3 plugins would have. So for the past few months I've been working hard on making this a reality, and at this stage every VST 3.7.1 feature has been implemented in yabridge's master branch and should in theory work, hence why I'm looking for other people to test some plugins and to report their findings.

Please let me know if you have any other questions!

Cheers,

Robbert

"dead and hacky code" lol.

LinVst is based on the first and original Wine bridge "Wacvst".

The code was laid out previously by the DSSI programmers and the Wacvst programmer and then additions from me.

The only focus LinVst has is for Latency/Speed and also to be pretty compatible with Reaper Linux and the approach is very much like C/Asm with realtime.

I'm not interested in programmers wanting pretty code to look at.

As for things like labels, well I think I've added that but no one has requested it so it's off by default and window resizing, just close the gui and reopen it but I have added that as well.

Any Wine bridge is going to depend on Wines's current state.

LinVst is not perfect and the way that Wine is means that no Wine bridge can be.

D2D1 is a huge problem and there are quite a few vst3's using it and also vst2's.

D2D1 needs to be sorted out in Wine by contributing to the Wine code.

I don't take any Wine bridge that seriously and I look at Wine bridges as helpers and native Linux plugins should be used first wherever possible.

I'm also not that interested in Vst3, I think it's a bloated pile of crap from Steinberg trying to still be relevant by introducing basically non essential features.

I did do LinVst3 as a quick thing that could easily be done and it works ok for quite a few vst3's that I've run but it is a basic implementation without the bells and whistles.

-------

As for this builtin Reaper wine bridge thing, take it up with Justin.

Wine is not stable/compatible enough and lacks too many features for a major DAW to support imo.

Last edited by osxmidi; 01-20-2021 at 09:05 PM.
osxmidi is offline   Reply With Quote
Old 01-20-2021, 09:12 PM   #9
Glennbo
Human being with feelings
 
Glennbo's Avatar
 
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,055
Default

Quote:
Originally Posted by osxmidi View Post
As for this builtin Reaper wine bridge thing, take it up with Justin.
Well how about a builtin beer bridge then? Surely you can make that happen!
__________________
Glennbo
Hear My Music - Click Me!!!
--
Glennbo is offline   Reply With Quote
Old 01-21-2021, 04:45 AM   #10
osxmidi
Human being with feelings
 
Join Date: Feb 2014
Posts: 620
Default

Quote:
Originally Posted by Glennbo View Post
Well how about a builtin beer bridge then? Surely you can make that happen!
No problems

Last edited by osxmidi; 01-21-2021 at 05:19 AM.
osxmidi is offline   Reply With Quote
Old 01-21-2021, 06:48 AM   #11
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

Quote:
Originally Posted by osxmidi View Post
As for this builtin Reaper wine bridge thing, take it up with Justin.
Michael continually posts about this even though he should very well understand it will never happen. And now apparently also he expects 32 to 64 bit Windows VST bridging in Linux on top of that, despite knowing that is accomplished by running a separate (32 bit) instance of Reaper. It's embarrassing at this point especially when he claims he's a programmer.

Last edited by JamesPeters; 01-21-2021 at 07:18 AM.
JamesPeters is offline   Reply With Quote
Old 01-21-2021, 09:01 AM   #12
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by JamesPeters View Post
Michael continually posts about this even though he should very well understand it will never happen. And now apparently also he expects 32 to 64 bit Windows VST bridging in Linux on top of that, despite knowing that is accomplished by running a separate (32 bit) instance of Reaper. It's embarrassing at this point especially when he claims he's a programmer.
By the way, yabridge does do bit bridging. Yabridge will detect whether the VST2 plugin .dll file or the VST3 module you're trying to load is 32-bit or 64-bit, and depending on that it will launch either `yabridge-host.exe` or `yabridge-host-32.exe` (or the `yabridge-group*` variants if you're using plugin groups) accordingly. That lets you use 32-bit Windows plugins in 64-bit Linux plugin hosts.
robbert-vdh is offline   Reply With Quote
Old 01-21-2021, 11:41 AM   #13
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by robbert-vdh View Post
In theory DAWs could integrate similar functionality, but without even considering the licensing aspects the main deal breaker here would be support.
That is why I suggest integrating yabridge functionality in a 3rd party Reaper extension- Maybe by this yabrige-enabling and searching for loading a plugin onto a track might be rendered transparent to the end user.

-Michael
mschnell is offline   Reply With Quote
Old 01-21-2021, 11:43 AM   #14
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by JamesPeters View Post
Michael continually posts about this.
Everybody has their dreams
In theory anything might be doable. If the effort is viable for the different cases can be discussed - and dismissed if appropriate.

-Michael
mschnell is offline   Reply With Quote
Old 01-21-2021, 11:55 AM   #15
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
Default

I just installed this to test vst3. Got fabfilter vst3 running but haven't done more than just load a few plugins. Looking good so far!

One thing I noticed is that it changes the priority of reaper's gui thread to sched_fifo priority 5, so something isn't quite right.

I did submit a pull request to linvst that for some reason never made it into the code base (AFAIK). The idea was that every time that reaper called into the vstbridge the thread would check the priority and class of itself, and then communicate that info to the wine side so that it could set the same values before executing any code. Like that the threads on the wine side would automatically use the priorities that reaper has set and not some arbitrary hard coded values. I don't think this would introduce any significant code execution latency overhead, especially after having had to syncronize threads between the linux and the windows side using some kind of IPC..

On the linux side it would do "pthread_getschedparam(pthread_self(), &policy, &param);"

Then it would pass that together with the rest of the needed data to the windows side, where it would do "pthread_setschedparam(pthread_self(), policy, &param);" before doing anything else.

Hopefully you can implement something like that instead of hard coding the priority and class?
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)

Last edited by Jack Winter; 01-21-2021 at 12:01 PM.
Jack Winter is offline   Reply With Quote
Old 01-21-2021, 12:00 PM   #16
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
Default

Quote:
Originally Posted by mschnell View Post
That is why I suggest integrating yabridge functionality in a 3rd party Reaper extension- Maybe by this yabrige-enabling and searching for loading a plugin onto a track might be rendered transparent to the end user.

-Michael
Did you try it? It really is quite painless.

Install windows plugins in wine. Run yabridgectl to add the path to the plugins, then run yabridgectl sync and finally start reaper which will pick up the new plugins. I've had much worse problems installing plugins on windows in the past!
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Jack Winter is offline   Reply With Quote
Old 01-21-2021, 12:04 PM   #17
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by Jack Winter View Post
I just installed this to test vst3. Got fabfilter vst3 running but haven't done more than just load a few plugins. Looking good so far!

One thing I noticed is that it changes the priority of reaper's gui thread to sched_fifo priority 5, so something isn't quite right.

I did submit a pull request to linvst that for some reason never made it into the code base (AFAIK). The idea was that every time that reaper called into the vstbridge the thread would check the priority and class of itself, and then communicate that info to the wine side so that it could set the same values before executing any code. Like that the threads on the wine side would automatically use the priorities that reaper has set and not some arbitrary hard coded values. I don't think this would introduce any significant latency overhead, especially after having had to syncronize threads between the linux and the windows side using some kind of IPC..

On the linux side it would do "pthread_getschedparam(pthread_self(), &policy, &param);"

Then it would pass that together with the rest of the needed data to the windows side, where it would do "pthread_setschedparam(pthread_self(), policy, &param);" before doing anything else.

Hopefully you can implement something like that instead of hard coding the priority and class?
Good catch, on the Linux side of things we should just check if we're already using SCHED_FIFO and then noop if that's already set. Hadn't though about that!

The default priority of 5 is based on jack2's default priority of 10 and the default priorities I've seen other DAWs using. These priorities could be synchronized between the plugin and the host, but do you think that would really make a difference? In the end any processing work has to finish before the current processing cycle, and whether the scheduler prioritizes the Wine plugin host or the DAW shouldn't make a huge difference in terms of processing latency.
robbert-vdh is offline   Reply With Quote
Old 01-21-2021, 12:20 PM   #18
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by Jack Winter View Post
Did you try it? It really is quite painless.
I don't have any doubt that I can do it. (But not really an urge until Reaper Linux with bridged Windows VSTs is know to outperform Reaper Windows.)

But the goal is to make Reaper / Linux available for non-techies.

-Michael
mschnell is offline   Reply With Quote
Old 01-21-2021, 12:35 PM   #19
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
Default

Quote:
Originally Posted by robbert-vdh View Post
The default priority of 5 is based on jack2's default priority of 10 and the default priorities I've seen other DAWs using. These priorities could be synchronized between the plugin and the host, but do you think that would really make a difference? In the end any processing work has to finish before the current processing cycle, and whether the scheduler prioritizes the Wine plugin host or the DAW shouldn't make a huge difference in terms of processing latency.
Well I've never ran JACK at such a low priority. I normally run JACK or Reaper at around 80 so that the audio processing threads run at a higher priority than the default sched_fifo that all the softirqs run at if using a kernel exposing that functionality. The basic idea is to set the softirq for your audio hardware really high, like 95 or so, then the audio threads higher than all the threads servicing hardware irqs (at 50). You wouldn't want your audio to have to wait on some slow hardware response like hard disk or USB.

I like the elegance of my proposal and patched linvst a long time on my own system to get this effect. Does it help, I'm not sure if it really does in practice, but in theory it ought to do! The elegance lies in the fact that I can change the priority in reaper and it will change automatically in the plugins, just like there was no IPC and separate threads. Reaper calls some GUI or setup function and it runs normal priority, reaper calls an audio processing function and it automatically gets the priority that reaper intended for that audio processing.

I suppose I could dig into the code and implement it myself, but I don't have much time and it will surely take me a day or two to read the code and wrap my mind about how it works.. I'm not all that young and bright anymore!
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Jack Winter is offline   Reply With Quote
Old 01-21-2021, 12:51 PM   #20
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by Jack Winter View Post
Well I've never ran JACK at such a low priority. I normally run JACK or Reaper at around 80 so that the audio processing threads run at a higher priority than the default sched_fifo that all the softirqs run at if using a kernel exposing that functionality. The basic idea is to set the softirq for your audio hardware really high, like 95 or so, then the audio threads higher than all the threads servicing hardware irqs (at 50). You wouldn't want your audio to have to wait on some slow hardware response like hard disk or USB.

I like the elegance of my proposal and patched linvst a long time on my own system to get this effect. Does it help, I'm not sure if it really does in practice, but in theory it ought to do! The elegance lies in the fact that I can change the priority in reaper and it will change automatically in the plugins, just like there was no IPC and separate threads. Reaper calls some GUI or setup function and it runs normal priority, reaper calls an audio processing function and it automatically gets the priority that reaper intended for that audio processing.

I suppose I could dig into the code and implement it myself, but I don't have much time and it will surely take me a day or two to read the code and wrap my mind about how it works.. I'm not all that young and bright anymore!
I don't think it would make that much of a difference (unless those USB interrupt threads you were talking about threads are actively spinlocking, in which case they should feel ashamed of themselves ), but inheriting the priority if set on both sides does make sound reasonable. I already added a check to not override the thread priority if something has already been set, but I'll change yabridge's scheduling mechanism to use the host's priority on both the Wine and the plugin side if the host is already using realtime scheduling in a bit. Yabridge already has a mechanism for communicating configuration between the plugin and the host (so you can apply plugin-specific options through a configuration file), so this should be a trivial change.
robbert-vdh is offline   Reply With Quote
Old 01-21-2021, 12:52 PM   #21
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
Default

It's really hard to benchmark these things. To me the biggest bottle neck in wine is that the wineserver is single threaded and can only service one request at a time, so if something takes a while to do, then your basically out of luck and your audio processing might suffer. Hopefully the wine devs will solve this someday, they just asked for comments about adding a kernel module to help them: https://lore.kernel.org/lkml/f4cc1a3...avers.com/T/#u

There are also other things that can go wrong on linux, for instance if you use SMT a lower priority thread could run on a sibling CPU and cause your audio thread to slow down or even to lose it's cache..

But in theory making sure that your soundcard interrupt and audio processing threads are executed before anything else does make a lot of sense. And to have the plugin audio processing run at the same priority that reaper's audio processing threads instead of an arbitrarily hard coded priority can IMO only be a good thing.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Jack Winter is offline   Reply With Quote
Old 01-21-2021, 01:15 PM   #22
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
Default

Thank you for considering this change, I'll be really happy to try it out!

Sadly there is no easy way to get rid of the need to synchronize threads on the linux and wine side.. The only solution would be if Reaper itself asked the wine vst host to create it's audio threads, those threads could be used both on the linux as well as the wine side and like that you could get rid of the need for synching. But that would probably limit it to using only a single wine prefix and would require a native reaper solution and it's not something we can add as a third party.

We did something like that with JACK and wineasio, wineasio would register a callback that JACK called to create the audio processing thread which then got passed back to JACK. Once JACK used that thread for the audio processing callback we could get rid of the semaphores and the thread could copy data back and forth between wine and linux. No need for any IPC at all anymore.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Jack Winter is offline   Reply With Quote
Old 01-21-2021, 04:52 PM   #23
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Hi Robert, I can help test on my system if you'd like.

I've got one question on yabridge vs LinVST though. Is yabridge capable of sharing memory between plugin instances? This is something that is very important for plugins like Kontakt. It means that if you load two instances of the same instrument, it won't take up double the memory.

With LinVST there is a LinVST-X version which allows you to share memory. In addition to the regular version which does not. Thus, you can choose the LinVST-X bridge for plugins that need memory sharing and the regular LinVST version for plugins that don't need memory sharing which is very convenient.

Someone else wrote a utility called LinVST Manager which then lets you select between these 4 different bridges - LinVST (vst2), LinVST-X (vst2 shared memory), LinVST3 (vst3) and LinVST3-X (vst3 shared memory). The utility then allows you to wrap each plugin with whatever bridge you would like.

While I don't doubt you have put a ton of work into this, at the end of the day the convenience factor is important, especially when working with a lot of plugins. Having one utility to manage all the plugins and having the ability for the plugins to share memory are pretty critical to me.

Just wondering where yabridge stands with this as I have not used it yet.

Thanks so much for your work!
Klangfarben is offline   Reply With Quote
Old 01-21-2021, 05:01 PM   #24
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by Klangfarben View Post
Hi Robert, I can help test on my system if you'd like.

I've got one question on yabridge vs LinVST though. Is yabridge capable of sharing memory between plugin instances? This is something that is very important for plugins like Kontakt. It means that if you load two instances of the same instrument, it won't take up double the memory.

With LinVST there is a LinVST-X version which allows you to share memory. In addition to the regular version which does not. Thus, you can choose the LinVST-X bridge for plugins that need memory sharing and the regular LinVST version for plugins that don't need memory sharing which is very convenient.

Someone else wrote a utility called LinVST Manager which then lets you select between these 4 different bridges - LinVST (vst2), LinVST-X (vst2 shared memory), LinVST3 (vst3) and LinVST3-X (vst3 shared memory). The utility then allows you to wrap each plugin with whatever bridge you would like.

While I don't doubt you have put a ton of work into this, at the end of the day the convenience factor is important, especially when working with a lot of plugins. Having one utility to manage all the plugins and having the ability for the plugins to share memory are pretty critical to me.

Just wondering where yabridge stands with this as I have not used it yet.

Thanks so much for your work!
Yabridge has the concept of plugin groups, which are user definable groups of plugins that will all be hosted in a single process. That way you can for instance have all instances of a single VST2 plugin, all plugins by a specific manufacturer, or just all of your plugins hosted inside of a single process. All of that and a few more compatibility options can be configured on a per plugin basis through a yabridge.toml file that contains globs matching relative plugin paths.

And for managing your plugins, yabridge comes with an officially supported utility called yaridgectl. With yabridgectl you add your Windows VST2 and VST3 plugin directories once, and you then just run `yabridgectl sync` every time you install a new plugin or update yabridge itself. Yabridgectl will then find all VST2 and VST3 plugins, set up yabridge for them, and do a few post-installation checks to make sure that everything's going to work fine.

Oh and on an unrelated but important note, I just noticed an error in yabridge's VST3 implementation that will require a backwards incompatible fix. Basically, COM UIDs as used in Steinberg's VST3 SDK have different byte orders on Windows and non-Windows platforms, and because yabridge silently copied the IDs reported by the plugin these IDs are now actually incorrect. This means that with the current master branch version of yabridge you won't be able to load project files created on Windows or project files containing the Linux VST3 version of the same plugin. I'll fix this soon, but it sadly requires a backwards incompatible change.

Last edited by robbert-vdh; 01-21-2021 at 05:19 PM. Reason: Fixed a typo
robbert-vdh is offline   Reply With Quote
Old 01-21-2021, 05:28 PM   #25
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Thanks Robbert for the very in-depth answers.

Quote:
Originally Posted by robbert-vdh View Post
Yabridge has the concept of plugin groups, which are user definable groups of plugins that will all be hosted in a single process.
Because I'm stupid, does having the plugins in a single process mean that they also can share memory if the plugin supports that? I'm assuming yes, but again, stupidity...

Also, can you create plugin groups within yabridgectl itself?
Klangfarben is offline   Reply With Quote
Old 01-21-2021, 05:34 PM   #26
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by Klangfarben View Post
Thanks Robbert for the very in-depth answers.



Because I'm stupid, does having the plugins in a single process mean that they also can share memory if the plugin supports that? I'm assuming yes, but again, stupidity...

Also, can you create plugin groups within yabridgectl itself?
If they're hosted in a single process they can use global variables to share memory, yes.

No you cannot define plugin groups within yabridgectl itself. Yabridgectl is really a fire and forget kind of thing, and managing configuration files with all the different options available would greatly increase complexity. All configuration happens through simple text files that looks like this.
robbert-vdh is offline   Reply With Quote
Old 01-21-2021, 11:52 PM   #27
wastee
Human being with feelings
 
Join Date: Mar 2015
Location: Mainland China
Posts: 157
Default

Great job!

I still using vst2 with yabridge. Haven't try a lot in using vst3.

I love yabridgectl. I wrote a personal script to do things like yabridgectl when using Linvst. Linvst is a great too. Thanks for your great job.

Is "yabridge support windows vst3" means Linux users can use melodyne vst3 with REAPER ARA2 support? Melodyne is the only one vst3 plugin i'm using in Wine REAPER in this moment.

Last edited by wastee; 01-22-2021 at 12:02 AM.
wastee is offline   Reply With Quote
Old 01-22-2021, 01:22 AM   #28
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by robbert-vdh View Post
If they're hosted in a single process...
But hopefully they don't share the same OS thread if they are installed in different tracks ?!?!?
-Michael

Last edited by mschnell; 01-22-2021 at 06:30 AM.
mschnell is offline   Reply With Quote
Old 01-22-2021, 03:18 AM   #29
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by wastee View Post
Great job!

I still using vst2 with yabridge. Haven't try a lot in using vst3.

I love yabridgectl. I wrote a personal script to do things like yabridgectl when using Linvst. Linvst is a great too. Thanks for your great job.

Is "yabridge support windows vst3" means Linux users can use melodyne vst3 with REAPER ARA2 support? Melodyne is the only one vst3 plugin i'm using in Wine REAPER in this moment.
I've chatted with Celemony for a bit and while we cannot support ARA just yet (everything's completely closed source at the moment), they said that they'll be open sourcing the ARA SDK under an Apache license in one to two months. They also said that it would come with experimental Linux support and that integrating it in yabridge should be fairly simple, so I'm really excited to see how that will turn out. Melodyne without ARA still works as expected of course at the moment.
robbert-vdh is offline   Reply With Quote
Old 01-22-2021, 06:17 AM   #30
wastee
Human being with feelings
 
Join Date: Mar 2015
Location: Mainland China
Posts: 157
Default

Quote:
Originally Posted by robbert-vdh View Post
I've chatted with Celemony for a bit and while we cannot support ARA just yet (everything's completely closed source at the moment), they said that they'll be open sourcing the ARA SDK under an Apache license in one to two months. They also said that it would come with experimental Linux support and that integrating it in yabridge should be fairly simple, so I'm really excited to see how that will turn out. Melodyne without ARA still works as expected of course at the moment.
I look forward to what will happen next. Thanks for your work!
wastee is offline   Reply With Quote
Old 01-22-2021, 03:20 PM   #31
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

I wanted to give a heads up with regards to those breaking changes I was talking about. I've fixed the VST3 class ID byte ordering, meaning that projects containing VST3 plugins saved on Windows can now be opened with the Linux version of REAPER and yabridge like you would expect. This does mean existing projects containing VST3 plugins running through yabridge from before this change will no longer load after updating, since the identifiers REAPER uses to identify specific plugins have changed. I've spent today working on a set of migration scripts that can rewrite old REAPER, Ardour, Bitwig and Renoise project files to reflect these changes. You can find them here along with instructions on how to use them: https://github.com/robbert-vdh/yabri...ools/migration

Sorry for the inconvenience, but I'm very glad someone pointed this out to me an actual release!
robbert-vdh is offline   Reply With Quote
Old 01-22-2021, 04:11 PM   #32
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by robbert-vdh View Post
If they're hosted in a single process they can use global variables to share memory, yes.
So, I went through the read me doc. It seems plugin groups are for the purpose of inter-plugin communication and don't seem to provide much benefit other than faster plugin instanciation?

More importantly, wouldn't running plugin groups in a single process massively reduce the amount of available CPU? Say I have Kontakt and Play in their own plugin group. There wouldn't be enough CPU to play more than an instrument or two if they are all using a single process, yes? If this is really the case, this doesn't seem to be a good solution for sharing memory between instances. Apologies if I'm misunderstanding here.

Quote:
Originally Posted by robbert-vdh View Post
All configuration happens through simple text files that looks like this.
I think text files are a simple solution until you have to deal with a lot of plugins. Then it becomes less so. Below is a screenshot of LinVST Manager, which shows you what is enabled/disabled, which bridge a plugin is currently using, lets you enable and disable specific plugins etc. all in the main window.



I know your goal here isn't to streamline things, but it would be hard to lose functionality like that, especially when dealing with a lot of plugins. It's one thing to do this on my test linux rig where I don't have a lot of plugins installed, and something much different doing it on a studio rig.

Just my two cents. I will install and give yabridge as fair a shake as I can.
Klangfarben is offline   Reply With Quote
Old 01-22-2021, 04:38 PM   #33
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Quote:
Originally Posted by Klangfarben View Post
So, I went through the read me doc. It seems plugin groups are for the purpose of inter-plugin communication and don't seem to provide much benefit other than faster plugin instanciation?

More importantly, wouldn't running plugin groups in a single process massively reduce the amount of available CPU? Say I have Kontakt and Play in their own plugin group. There wouldn't be enough CPU to play more than an instrument or two if they are all using a single process, yes? If this is really the case, this doesn't seem to be a good solution for sharing memory between instances. Apologies if I'm misunderstanding here.
Hosting multiple plugins in a single process is the normal way to host plugins! REAPER does that (unless you enable the bridges), Ardour does that, Renoise does that, Bitwig does that depending on how you set the sandboxing, and every other commercial DAW on Windows and macOS also does it. Hosting multiple plugins in a single process means that you load all of those plugin's libraries in a single process, rather than having to create a dedicated process for each plugin instance. This lets those plugins share resources through global variables and in some cases also pool work (the Spitfire plugins become much more CPU friendly when you use plugin groups).

Quote:
Originally Posted by Klangfarben View Post
I think text files are a simple solution until you have to deal with a lot of plugins. Then it becomes less so. Below is a screenshot of LinVST Manager, which shows you what is enabled/disabled, which bridge a plugin is currently using, lets you enable and disable specific plugins etc. all in the main window.

<snip screenshot>

I know your goal here isn't to streamline things, but it would be hard to lose functionality like that, especially when dealing with a lot of plugins. It's one thing to do this on my test linux rig where I don't have a lot of plugins installed, and something much different doing it on a studio rig.

Just my two cents. I will install and give yabridge as fair a shake as I can.
The goal of yabridge very much is to streamline things! Hence why yabridge's configuration system is a thing. The alternative would be having to recompile a version of yabridge with all of those settings baked in, and then you'd have to manage multiple separate versions of yabridge and assign those to specific plugins. LinVstManager does exactly that out out of necessity, but with yabridge you can just apply custom compatibility options to individual plugins or to groups of plugins through a simple human readable TOML configuration file.

Last edited by robbert-vdh; 01-22-2021 at 04:38 PM. Reason: Got rid of the screenshot in the quote
robbert-vdh is offline   Reply With Quote
Old 01-23-2021, 02:54 PM   #34
kytdkut
Human being with feelings
 
kytdkut's Avatar
 
Join Date: May 2017
Posts: 95
Default

Quote:
Originally Posted by Klangfarben View Post
LinVST Manager
last time I checked you could use LinVST Manager with yabridge


EDIT = won't work for VST3

but yabridgectl is real easy to configure, you just add a directory, sync, point REAPER to wine vst folder, scan

easier with vst3, add, sync, scan (~/.vst3 is already being scanned by REAPER by default)

Last edited by kytdkut; 01-23-2021 at 03:02 PM.
kytdkut is offline   Reply With Quote
Old 01-23-2021, 09:51 PM   #35
Soli Deo Gloria
Human being with feelings
 
Soli Deo Gloria's Avatar
 
Join Date: Oct 2013
Location: Argentina
Posts: 1,303
Default

Hi everyone!

I'm chiming in just to comment briefly about my experience with Yabridge. I ended up in Manjaro, after going back and forth between Ubuntus, and Yabridge has been performing awesomely well in my case. In fact, after having a lot of performance problems in the past with the Ubuntus, the combination of Manjaro, Yabridge and a fork of Wine called Wine TKG ( https://github.com/Frogging-Family/w...4.r0.g350eb136) has allowed me to use Kontakt and other heavy stuff in Linux in a similar way to Windows (with an expected but rather small and absolutely negotiable dose of overhead).

Robbert's feedback during this time has been absolutely priceless. As he has kindly pointed out to me during my transition, the main bottlenecks regarding Windows plugins in Linux lay both in the kernel used by Ubuntu and many other distros, together with some inherent lacks in the Wine department, solved by Wine TKG, Wine-Nspa and possibly other forks. And what's even more bizarre is that, at least in Manjaro, most of the suggested audio tweaks that dozens of threads/sites recommend here and there, in fact seem to hurt the performance notably, as I could test out myself. All I have needed in Manjaro is to add my user to the audio group, set the CPU governor to performance, and enable this variable in /home/.profile for Wine TKG to perform its magic :

export WINEFSYNC=1

This topic alone deserves its own thread, I know, which I'll open. Anyway, I just want to say that Yabridge is a wonderful bridge which loads things in a fast and elegant way and performs incredibly well. And, on top of that, since it is a free and open-source project, you can be sure that I don't have any corporate affiliation or any other kind of commercial interest in this.

My two cents, as they say...
Soli Deo Gloria is offline   Reply With Quote
Old 01-23-2021, 10:11 PM   #36
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

Quote:
Originally Posted by Soli Deo Gloria View Post
And what's even more bizarre is that, at least in Manjaro, most of the suggested audio tweaks that dozens of threads/sites recommend here and there, in fact seem to hurt the performance notably, as I could test out myself. All I have needed in Manjaro is to add my user to the audio group, set the CPU governor to performance, and enable this variable in /home/.profile for Wine TKG to perform its magic :

export WINEFSYNC=1
I find most tweaks people mention for Linux DAW use don't matter or make things worse overall, unless you're using a system that requires Jack and connecting various applications (standalone synths + DAWs for instance). If you are using Reaper but not Jack, I'm guessing some of those tweaks just aren't needed, and those tweaks came about as a result of people using other DAWs in Linux (which required you to use Jack at the time since that was the only option).

What I do for my OS configuration is posted here in case anyone wants to compare. The part about fstrim.timer might interest you in particular since it's not enabled in Manjaro by default (to my surprise). This would affect SD Card, SSD, and NVMe drives. (Apparently this is also the case for Fedora.)

I hope I didn't sidetrack this thread too much either.
JamesPeters is offline   Reply With Quote
Old 01-23-2021, 10:41 PM   #37
Soli Deo Gloria
Human being with feelings
 
Soli Deo Gloria's Avatar
 
Join Date: Oct 2013
Location: Argentina
Posts: 1,303
Default

Thanks for the fstrim.timer tip, James! I'll check it out tomorrow and add it to my Manjaro audio configurations thread, as a quote from you .


I use Jack, in fact, but I don't combine any standalone thing, only Reaper as a DAW with its internal/VST plugins. The fstrim thing could probably add some additional overhead to the performance, which could only be great. I'll comment later on the other thread.



And sorry if I derailed this thread a little, but I just wanted to point out the great experience with Yabridge in the Manjaro - Wine TKG context.
Soli Deo Gloria is offline   Reply With Quote
Old 01-24-2021, 05:03 AM   #38
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by Soli Deo Gloria View Post
... Ubuntu ... I just wanted to point out the great experience with Yabridge in the Manjaro - Wine TKG context.
Time to provide this as a "Reaper Linux-Distro" ?

-Michael
mschnell is offline   Reply With Quote
Old 01-24-2021, 01:04 PM   #39
Soli Deo Gloria
Human being with feelings
 
Soli Deo Gloria's Avatar
 
Join Date: Oct 2013
Location: Argentina
Posts: 1,303
Default

Há! I wouldn't dare to do such a thing, but no wonder if someone ends up doing something similar (which wouldn't be so far from something like AvLinux and the like)...
Soli Deo Gloria is offline   Reply With Quote
Old 01-26-2021, 04:10 PM   #40
robbert-vdh
Human being with feelings
 
Join Date: Nov 2020
Posts: 275
Default

Thanks to @kytdkut I found an issue in the VST3 audio processing routine that would with a low probability cause audio channels channels to randomly be muted in individual plugin instances in REAPER (since REAPER seems to be the only DAW on Linux that uses the VST3 silence flags feature). So if anyone's been testing this and noticed that some plugins are randomly not outputting any sound on their left and/or right channel, know that there's a fix for that! There have also been a lot of other fixes and quality of life improvements in the last week. Don't forget to rerun `yabridgectl sync` after updating!
robbert-vdh is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 12:40 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.