robbert-vdh / yabridge

A modern and transparent way to use Windows VST2, VST3 and CLAP plugins on Linux
GNU General Public License v3.0
2.48k stars 65 forks source link

REAPER freezes #29

Closed ghost closed 4 years ago

ghost commented 4 years ago

Problem description

System information

Debug log

Here are the Logs for the plugins I'm having trouble with

Archetype Plini

yabridge.log

Spitfire BBCSO Discover

yabridge.log

Spitfire LABS

yabridge.log

All of the above plugins work using LinVST, I just wanted to see if I got a bit of a better performance with your program! I also noticed in your README the section on the audio specific Wine version, I will definitely be checking that out. Nevertheless great work!!

robbert-vdh commented 4 years ago

I'm away from my desktop for a few days so I can't check for myself just yet, but from the looks of it REAPER doesn't properly handle the audioMasterUpdateDisplay callback. This issue is not present with LinVST because it silently ignores that function call and others like it. From my limited experience REAPER's plugin hosting can be a bit hit or miss (as in, plugins that work fine in any other VST host sometimes have issues in REAPER). I did have some success messing around with REAPER's plugin bridge settings, so maybe that's something you can try!

Oh and on an unrelated note just in case it was not intentional, the Wine prefix is overridden to /home/lyonelz/Wine/Audio through the WINEPREFIX environment variable so every plugin will be loaded using that Wine prefix.

ghost commented 4 years ago

I'll take a look at the plugin bridge settings! The Wine prefix being overridden is intentional.

Edit: Changing the bridge settings to "Run as: Separate Process" seems to have fixed it! Only problem now is that the UI is not scalable. Which isn't that big of a deal.

robbert-vdh commented 4 years ago

I did some digging around and I'm at least 95% sure this is a bug in REAPER's plugin GUI handling on Linux. It seems to come down to a timing issue, where REAPER freezes immediately when it receives audioMasterUpdateDisplay while it is calling effGetProgram as part of its UI updating routine. If I modify yabridge to also periodically call this function from a plugin that would otherwise run just fine under REAPER (such as OTT, which doesn't use audioMasterUpdateDisplay itself) then this also causes it to freeze. I assume the people over at Cockos made sure the Linux version works with properly with most native Linux VST plugins, and since those plugins probably don't use audioMasterUpdateDisplay they never ran into the issue themselves. This might be worth sending a bug report over.

robbert-vdh commented 4 years ago

I've added an option as a temporary workaround until this is fixed in REAPER. This is not ideal, but I think it's the best compromise at the moment and this will still allow you to use REAPER's regular non-bridged plugin hosting mode since REAPER's editor resizing seems to be broken when using their plugin bridges. See this comment in #32 for more information.

ghost commented 4 years ago

Awesome! Adding the config file in the VST folder did the trick. I'll leave it up to you if you wanna close the issue or not.

robbert-vdh commented 4 years ago

That great to hear! Yeah it might be a good idea to keep this issue open for visibility's sake until it gets fixed on REAPER's side.

robbert-vdh commented 4 years ago

So I've finally spent the time to actually investigate this better, and it comes down to a limitation of how communication in yabridge works and it's not really a problem with REAPER and Renoise per se. The issue has to do with nested/mutually recursive function calls. REAPER tells the plugin to update its GUI (effEditIdle), the plugin tells REAPER that parameters have been changed (audioMasterUpdateDisplay), and then REAPER asks the plugin for its MIDI program number (effGetProgram). This results in two host -> plugin function calls happening at the same time, and because we're using mutexes to prevent messages from arriving out of order this results in a deadlock. I'm going to try to come up with a solution that allow these kinds nested function calls, but this is probably going to be pretty difficult to pull off without adding more hacks since mutual recursion is sort of incompatible with the current implementation since everything that even potentially interacts with the GUI has to be run on the main thread because of Win32 API limitations.

So TL;DR: while the current workaround works, there's a better solution possible that doesn't involve any hacks, but actually implementing it that way is going to be fairly hard to impossible because of the programming model and API limitations.

robbert-vdh commented 4 years ago

Good news, this workaround will soon no longer be needed! I've been working on a complete rewrite of yabridge's communication model on the master branch that solves this issue and issues with many other similar situations that typical VST bridges would struggle with. Event handling is now fully concurrent and yabridge will spawn additional threads as needed to process the requests, so deadlocks or blocked event loops are no longer an issue. This also translates to better performance when scanning and opening plugins as well as many other subtle improvements. There's an in-progress changelog with all changes in the new version here. I still need to do some final cleanup and refactoring work, but I've been using it for the last week and it's been working great. Plugin groups are also rock solid now and can handle dozens of plugins without issues.

ghost commented 4 years ago

Good news, this workaround will soon no longer be needed! I've been working on a complete rewrite of yabridge's communication model on the master branch that solves this issue and issues with many other similar situations that typical VST bridges would struggle with. Event handling is now fully concurrent and yabridge will spawn additional threads as needed to process the requests, so deadlocks or blocked event loops are no longer an issue. This also translates to better performance when scanning and opening plugins as well as many other subtle improvements. There's an in-progress changelog with all changes in the new version here. I still need to do some final cleanup and refactoring work, but I've been using it for the last week and it's been working great. Plugin groups are also rock solid now and can handle dozens of plugins without issues.

That is fantastic news! Can't wait to try it. Thanks for the amazing work and effort my man!

robbert-vdh commented 4 years ago

This is now fixed as of yabridge 2.0.0! :tada:

The old workaround options has been removed since it's no longer needed.