Closed ghost closed 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.
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.
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.
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.
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.
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.
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.
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.
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!
This is now fixed as of yabridge 2.0.0! :tada:
The old workaround options has been removed since it's no longer needed.
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!!