Yabridge integration

[Rossmaxx]

Enhancement Summary

I feel it would be a good idea to integrate yabridge vst host into the lmms codebase. I discussed this on discord but didn't get much feedback and also, this one looks worthy of an issue.

The way I imagine the execution is for yabridge to be a submodule (or a dependency, whichever is better) which will be built as a plugin (but only for linux systems because it's linux only).

Justification

I am suggesting yabridge to be a vestige/current vst implementation replacement as the way we handle vst is very buggy (almost 40% of our bug reports come from vst issues if I'm right). We can keep our current implementation for backwards compat but imo, it should be phased out in favour of a better system.

Also, i know carla exists but even carla is buggy.

Another advantage I see is slimmer vst code and concentrate our vst implementation to windows alone (or use a bridge there too)

[sakertooth]

The only benefit I could see by using yabridge is having all Linux users use our Native Linux VST implementation, rather than loading a .dll and using our own Wine compatibility layer. However, we would still need an implementation to host both Windows and Linux VSTs, even if they are Windows-only and Linux-only implementations.

So are you trying to say to remove our compatibility layer for Linux using Wine, and force Linux users to use the Native Linux VST implementation? In that case, it may help (assuming our Linux VST implementation works better for Linux users, which I think is a valid assumption and it has been working better from what I can tell).

I wouldn't see a need for us to add a submodule. We can just make it so that for Linux users to use Windows VSTs, they would need to have yabridge installed and then we would direct them to yabridge's README on how to use it. I find using yabridge under the hood (the way it was meant to be used) a bit too intrusive on the users system.

[Rossmaxx]

The only benefit I could see by using yabridge is having all Linux users use our Native Linux VST implementation, rather than loading a .dll and using our own Wine compatibility layer.

That's a good enough benefit because well, most of the plugin issues do come from the wine compatibility layer and by removing that one, we can solve lots of issues plaguing the nightlies. This is just a workaround and not a solution.

assuming our Linux VST implementation works better for Linux users, which I think is a valid assumption

Exactly what i assumed.

However, we would still need an implementation to host both Windows and Linux VSTs, even if they are Windows-only and Linux-only implementations.

Yeah but atleast it'll be cleaner to maintain than whatever mess we have now. Also can just use OS specific files where needed instead of mangling stuff bw linux and windows. Helps to improve both linux and windows vsts in the long term.

We can just make it so that for Linux users to use Windows VSTs, they would need to have yabridge installed and then we would direct them to yabridge's README on how to use it.

It's ok that way but i just wanna avoid a carla situation here. That's why i suggested submodule.

But we will have to keep the wine layer for 1.3. But adding yabridge brings a better, more stable route to use windows vsts on linux.

[DomClark]

the way we handle vst is very buggy [and] it should be phased out in favour of a better system

I see this attitude surprisingly often, and always try to push back against it. If a feature has bugs, then the solution is not to remove that feature, but to fix the bugs.

almost 40% of our bug reports come from vst issues if I'm right

Where does this number come from? Also, how many of these issues are specific to Windows VSTs on Linux, which is the focus here, and not VST support in general?

most of the plugin issues do come from the wine compatibility layer

Yabridge uses Wine too. How do we know it won't face the same issues? The current assumption is that our problems are due to differences between the version of Wine we build with and the version of Wine installed on the user's system. If we integrate yabridge, it may well succumb to the same problems. To quote the yabridge readme:

First of all, yabridge requires a recent-ish version of Wine (Staging). Users of Debian, Ubuntu, Linux Mint and Pop!_OS should install Wine Staging from the WineHQ repositories as the Wine versions provided by those distro's repositories may be too old to be used with yabridge.

We could impose the same requirements, pull the latest Wine version in our CI jobs, and the problem may well evaporate.

Another advantage I see is slimmer vst code

Yeah but atleast it'll be cleaner to maintain than whatever mess we have now. Also can just use OS specific files where needed instead of mangling stuff bw linux and windows. Helps to improve both linux and windows vsts in the long term.

The existing code is a mess, and this refactoring is worth doing, but it isn't related to the current issue. There's very little Wine-specific code in the VST host; it's basically limited to getting a native X11 window ID for the plugin window. Most of the platform-specific code is unrelated to the Wine bridge.

But adding yabridge brings a better, more stable route to use windows vsts on linux.

We haven't tried it, so this is little more than wishful thinking.

I'd also like to address the general idea of integrating code from other programs to fix issues. We've had such suggestions many a time for audio recording - "just integrate the Audacity code into LMMS". More often than not, the problem itself is not difficult to fix, and the integration is the difficult bit that is holding up progress. Receiving audio into the program is just a few API calls; putting it into tracks in real time, storing that data in the project, and suchlike is what is difficult, and won't be addressed by using someone else's code. Similarly, we already have a VST host - that's not the problem here. The difficulty is dealing with Wine, and we still have to do that with yabridge, along with a lot of extra work to actually do the integration.

Finally, it is worth pointing out that there is absolutely nothing stopping users using yabridge with the nightly already, and indeed some do.

[Rossmaxx]

@DomClark thanks for the clarification. I thought integrating yabridge might be an improvement but from what you say, there seems to be no real benefits.

Also, i got a random thought yesterday about weak linking yabridge (or whatever it's called, similar to what's done with carla). Which i think might be a better short term approach, while keeping and gradually fixing our current vst layer.

[DomClark]

Weak linking would allow yabridge to be used at runtime if it exists on the system. This is already possible, using the native Linux VST hosting capability of LMMS. I don't see a reason to think that whatever other host interface we might use to link to yabridge would be more stable than using our existing VST interface to do so. Also, doing so as a short term approach only makes sense if it would be less effort than fixing the current problem(s), which again I see no evidence for.

As I have mentioned before elsewhere, I think we should focus effort on fixing bugs, not writing workarounds. Workarounds are for dealing with problems in other people's code - why should a piece of software work around itself?

[enp2s0]

Would just like to add that as someone who uses LMMS's builtin compatibility layer as well as Yabridge to provide similar functionality in Ardour, I often find that LMMS is more reliable and stable than Yabridge. Especially since Yabridge seems to require a recent version of wine-staging to function properly (per its own documentation) which isn't packaged yet on many distributions and needs to be compiled/installed manually.

So it isn't entirely the case that Yabridge is a "better solution," in my experience it's actually worse in many cases.

[Rossmaxx]

Well, that's new.