Long-Term Possibility of Flatpak Compatibility?

[Eoin-ONeill-Yokai]

Feature description

There's been some discussion in other issues regarding users trying to use Flatpak versions of professional DAWs with Yabridge -- specifically #114 and #111 where it's been clarified that it's not technically possible to use flatpak w/ yabridge due to sandboxing at the moment. This has been mentioned in bitwig/bitwig-studio-flatpak#24 as well, which might be worth following up or discussing. Maybe if bitwig and yabridge could establish some communication here, it would be helpful!

My understanding of flatpak is pretty limited, but I was wondering if there could be some way to support flatpak distributions of DAWs while also supporting yabridged vst instruments.

Why?

While most DAWs provide some kind of .deb installer, there are certain systems (Fedora, Arch) where installing the flatpak version could lead to better stability (due to correct library usage within the DAW) while providing an easier installation process where software versions can be specified and maintained easily via Flathub. Because of this, it would be nice to eventually have Yabridge be compatible with flatpak daws.

Flatpak Extensions

My limited research on Flatpak resulted in finding out about Flatpak Extensions, which I think would allow Yabridge to provide a "add-on" environment onto standard Bitwig installations via flatpak. My understanding would be that it would look something like this:

flatpak install org.bitwig.Bitwig.Yabridge

Where the last domain represents the desired extension on top of the org.bitwig.Bitwig environment. This would provide the necessary environment for Yabridge (my understanding is basically LibBoost + Wine-Staging, but there's perhaps more necessary) which would then be optionally included within the sandboxed Bitwig instance. This extension would need to be uploaded and maintained within the flathub repository.

There might be more I'm missing here, as my understanding of this topic is pretty limited. If anyone happens to know more about Flatpak, it would be nice for some input here. Additionally, I'm not sure if a flatpak exension needs to be made by Bitwig, for instance, to get this working as expected or if the extension can be maintained separately by yabridge contributors.

Anyway, I'm mostly interested in this as a user who would like to use flatpak for most of my user-side installations for stability reasons. If anyone here has any insight on the issue, it would be nice to hear it.

[robbert-vdh]

You would need to package both Wine and yabridge in such a way that they can run inside of the Flatpak runtime. One crucial issue with using Flatpak for these things remains that it was always meant to sandbox individual applications, while DAW usage often involves integrating many separate components such as plugins (which include things like yabridge and hardware-specific plugins that depend on other applications running on the same system) and connected hardware. So I'm still not convinced that distributing DAWs through Flatpak is the correct solution to the packaging problem, but that's a different matter entirely of course. :smile:

But yeah, like I said, if both yabridge and a suitable version of Wine are available within the Flatpak runtime then everything would just work. The issue then becomes that yabridge consists of two sets of components: the plugin libraries (yabridge-{vst2,vst3}.so), and the plugin host binaries (yabridge-{host,group}{,-32}.exe{,.so}), and those versions need to match. So to be able to actually use yabridge for a plugin within a Flatpak container, you'd need to either:

• Package Wine and yabridge for Flatpak, install yabridge as normal outside of Flatpak (which I'll just call the host system from now on), set up yabridge for the plugins as normal on the host system using yabridgectl sync, and then as the user make sure the Flatpak environment is using the same version of yabridge you installed on the host system to avoid conflicts. This would still require the Flatpak container to have access to the Wine prefixes (I think Bitwig's Flatpak already removes the sandboxing for the entire home directory, but normally those things are sandboxed).
• Do the same thing, but use the yabridge plugin libraries packaged in the Flatpak runtime instead of the ones installed on the host system and also run yabridgectl from within the container. That would reverse the dependency issue, since you now cannot use those plugins with other non-Flatpak DAWs unless you have the same version of yabridge installed outside of Flatpak.
• Install Wine inside of the sandbox, and allow the container to directly use the yabridge version installed to the host system. This is probably the least headache introducing option since it sidesteps the whole dependency issue I talked about earlier, but this still would not work if yabridge is installed through the package manager (unless we're specifically talking about the yabridge-bin AUR package). In that case yabridge would be dynamically linked against Boost.Filesystem, so the same version of Boost that's used on the host system would also need to be available in the Flatpak container. That was the issue @drewofdoom had in https://github.com/bitwig/bitwig-studio-flatpak/issues/24. So this could only really work with a binary release of yabridge manually installed to ~/.local/share/yabridge.

[Thesola10]

I believe the Bottles project has already packaged Wine for Flatpak, and might be a plausible approach to sharing Wineprefixes between host and flatpaks (ideally).

One could imagine syncing the Wine version and runtime using a document portal between Bottles and any app using the yabridge Flatpak plugin. UX would be something like "Bitwig needs to run Windows software. Create or select a Bottle to use with Bitwig"

(ofc that approach requires work on the Bottles side of things, and potentially on yabridge too, but just imagine a standard, centralized way to manage Wineprefixes throughout the Flatpak ecosystem)

[David-Else]

Now that stable Wine itself is a Flatpak org.winehq.Wine can we use that? It perfect as every distro can use it, but there is no instructions or talk about it here.

[robbert-vdh]

Right now (this can of course change at any time) org.winehq.Wine and com.bitwig.BitwigStudio use the same Flatpak runtime so they'd in theory be able to be used together. Yabridge 4.0 at least sort of solves the out of sync issue with Flatpak+yabridge, but you'd still need yabridge packaged for Flatpak (if you expose the entire home directory than a manual/Ubuntu-style installation should also work if you run yabridgiectl outside of the Flatpak runtime, but this is also a bit hacky). So in theory you could be able to make it work, but Flatpak is simply not meant to be used with ecosystems like this so you may run into other problems.

[dreamcat4]

ok @robbert-vdh ... so in your opinion would there be any value in making a downstream versioned flatpak builds of yarbridge specifically targeting for bitwig only. To ensure that the wine versions can be kept in sync and lined up to match each other?

Perhaps the flatpak fully qualified name might be called com.github.<username>/yarbridge-bitwig or yarbridge-for-bitwig. Or something like that to appear as it's own seperate flatpak allongside the seperate bitwig flatpak. Since presumably we cannot make yarbridge a hard requirement of the official bitwig flatpak, at least not unless the Bitwig company ever chooses to do that.

Ok... so does that all sound like madness? or some kind of a path forwards here? (We would also need somebody else to come alone who is willing to create and maintain such a flatpak)

[robbert-vdh]

You could do that. But honestly, in my opinion Flatpak in its current form simply cannot work for software like DAWs and plugins that work together as an entire ecosystem. You may run into other issues, and once the Flatpak runtimes are starting to get upgraded you'll need to somehow upgrade the Flatpak build files for all packages at once or things may not be able to work together anymore.

[Eoin-ONeill-Yokai]

You may run into other issues, and once the Flatpak runtimes are starting to get upgraded you'll need to somehow upgrade the Flatpak build files for all packages at once or things may not be able to work together anymore.

Yeah, I tend to agree with you here now. Looking into this issue, it's fairly clear that Flatpak was not designed with DAWs in mind. Perhaps Flatpak portals will one day allow for some layers of inter-process communication.

For those who need a solution right now on a read-only desktop environment on a system like Fedora Silverblue: I strongly recommend you look into distrobox in which you can create a virtual distribution instance (for example, Ubuntu 22.04) where you install bitwig and yabridge and export the bitwigstudio application. This will allow you to containerize your entire DAW working environment and isolate your dependencies from the rest of your system. This can also help stability, in theory, since your wine / glibc / yabridge version(s) will only update when you explicitly enter the environment to do so.

I might make a quick setup docker image that installs yabridge and its dependencies, with only bitwig needing to be supplied to the user.

[mitermayer]

Just hoping into this thread, I really would love to have a world where I can have a container with bitwig and vst support. Currently spending a considerable amount of time debugging why my wine stopped working

[korewaChino]

+1 for this. I'd really love to be able to install my plugins in a Bottles container and use my Windows DAWs inside the bottle, while also loading VST plugins from there.

[CleoMenezesJr]

I packaged Reaper to Flatpak, and now I'm just wondering the same thing. https://github.com/flathub/fm.reaper.Reaper Any news? :/

[Eoin-ONeill-Yokai]

I've been looking into this a bit but I still don't know how to do it.

In theory, if you can create an extension for your DAW packaging that installs: - Wine version compatible with YB - Yabridge/YabridgeCTL

You could then run yabridgectl from the command line by doing something like (not verbatim, but in essence)

flatpak run --command=/bin/yabridgectl com.SomeCompany.SomeAwesomeDaw sync

In which case yabridge would be able to run w/ wine within the container, and yabridge would be able to export .so files appropriately. @CleoMenezesJr If you're in charge of managing the Reaper Flatpak you might understand all of this better than me, as most of my knowledge is only based on examining other flatpak repositories that deal with extensions (See Valve's Steam flatpak package with optional Gamescope Extension, which isn't flawless but is close.)

The thing I don't know is how to create an extension that can be used as extensions to arbitrary flatpak applications. Ideally, the Reaper daw wouldn't have it's own yabridge extension but would create one that can be reused by other Daws as configured by their flatpak configuration files.

[rcsilva83]

I may have misundestood what you're discussing, but if you're talking about using a Yabrigde Flatpak to make any plugin available to a Flatpak DAW, I don't think it's the way it is supposed to be implemented. Audio plugins are available to Flatpak DAWs through plugins packaged in Flatpaks (example).

So, I think the way to use Yabridge in "Flatpak Way" would be to package a Windows plugin as a Flatpak, bundled with Wine and Yabridge.

[Eoin-ONeill-Yokai]

@rcsilva83 I think the problem with that implementation is that it assumes that people will be willing or have the rights to redistribute any plugin as a flatpak. For open source plugins, this is indeed a fine solution, but it's definitely not an option for plugins that are arbitrarily distributed (e.g. Kontact libraries, IK Multimedia, what have yous and what nots) since most of those cannot be redistributed without proper licensing.

[rcsilva83]

@Eoin-ONeill-Yokai yes, I agree with you. As I read your reply I had an idea but I don't know if it's feasible. If we had an Yabridge Flatpak, I think it would be easy enough to package most plugins in Flatpak. So easy that it could be done with a script. What if yabridgectl shipped such script? For example, it could be created a yabridgectl flatpak option that would build a Flatpak and install locally, so it could be used with Flatpak DAWs.

[abique]

One idea would be to have:

1. a clap plugin service daemon, it'd be reachable from flatpak or any app which has access to the daemon's socket
2. a proxy clap plugin, so the host speaks to the proxy clap plugin which itself speaks to the daemon to create a new plugin instance, and the to the plugin instance itself
3. a clap plugin host proxy: spawned by the daemon, and hosts the plugin

I recap:

• the daemon has knowledge of all the plugins avail on the system
• the daemon can create plugin instance and give you shm/socket to talk to it
• everything is transparent for both plugin and hosts, it is just a "proxy / man in the middle" technology
• this way we can distribute the plugin host in every flatpak runtimes, as well as for the system
• plugins can be sandboxed (no network, no file access, ...)

[abique]

The strong point of this approach is that it allows host and plugin built for different runtimes to work together. In a way it is already what's yabridge is doing with wine: bitwig <-> yabridge proxy <-> wine process with yabridge host <-> windows plugin. Now that'd be: bitwig <-> clap-daemon-proxy <-> clap-daemon and once the plugin instance is created: bitwig <-> clap-plugin-proxy <-> clap-host-proxy <-> plugin.

Am I clear?

[rcsilva83]

@abique, I'm not familiar with CLAP, I just use Yabridge with a VST3 plugin. Is this deamon needed for VST3 too?

[dreamcat4]

Am I clear?

If i am not misunderstanding... we were missing a clarification that CLAP is a new plugin standard to replace or go allongside VSTs.

So in this conversation it's a welcome 'also too'. Because of the possibility of porting existing JUCE library based VSTs over to CLAP. And because CLAP is just more modern, better, with fewer licencing issue too. Sine was alluded about being unable to distribute publically a VST flatpaks.

So it's most welcome. But allongside (both) since cannot replace (either-or) ?

[deusnovus]

For the sandbox thing to still be an issue with yabridge, I would imagine that Flatseal being able to provide filesystem access to every flatpak app is not that big of a development, no?

[robbert-vdh]

The situation is still the same. Someone would need to package both yabridge and Wine for the same Flatpak runtime the DAWs are running under. That wouldn't be too much effort, but it's something someone would need to do. You could also do it without packaging anything by just setting some oaths but that's not a very convenient or reproducible solution (and also, much more work than not simply not using Flatpak at all).

[ArtikusHG]

I have no idea why this hasn't been mentioned yet, but Wine is already available as a Flatpak and has been for a while. It is unofficial, but looks like it's well and actively maintained - the last update was 3 months ago, and includes the current stable version of Wine released around the same time (8.0.2).

Packaging yabridge should (probably?) be significantly easier than packaging Wine. I might try to in my free time.

EDIT:

As per Flatpak documentation:

Unlike other flatpak commands, flatpak-spawn is available to applications inside the sandbox. It runs COMMAND outside the sandbox, either in another sandbox, or on the host.

This allows us to create a yabridge + wine package, and then DAWs could call to this package and spawn plugins, though this would probably require some small changes to yabridge itself, it shouldn't be too hard (?)

[xnghu]

+1 for wanting to see this happen, waiting patiently- while also reading up on material I need to learn to be able to help

[ejaa3]

Please read my mention, thanks.