yabridge
yabridge copied to clipboard
robbert-vdh
Wayland version (or maybe something else) to make plugins work with Studio One Linux with GUI
Feature description
I think no Linux user uses Studio One because no plugins work with GUI, except embedded. Everyone is waiting for proper plugin support (I know this from the Presonus forum, which is closed now). If there was a Yabridge fork or version that allows this, everyone will be happy. People could buy S1 Linux, Presonus could sell more S1 Linux. If I was a developer, I would ask Presonus to donate this idea, it is a win-win :)
Anything else?
No response
Presonus have a wayland wrapper for vsts but I'm not sure whether yabridge could make use of this in conjunction with wine's wayland support to allow for GUIs in studio one. Currently yabridge is x11 only.
https://github.com/fenderdigital/presonus-plugin-extensions/blob/main/ipslwaylandframe.h
It would be great to have wayland support and even better to have at least some GUIs for 3rd party plugins working in Wayland but the way Presonus have gone about this doesn't seem likely to work out. I have plugins on my system that aren't being developed anymore. There's no way these are getting an update to work in Studio One. Putting the onus on the plugin developer seems unlikely to work. If it can be included in JUCE, maybe that's a way forward at least for new native plugins . Probably it would be better if Presonus allowed plugins GUIs to run through XWayland, then suddenly many plugins would be available.
I feel your pain though, I'd love to be able to test Studio One properly but the lack of GUIs is a bigger showstopper than JUCE8.
If anyone wants to start working on this, feel free to reach out to me. I can't provide the implementation, but I can help with testing and debugging or answer general questions regarding the interface and Wayland in general.
Julian Wolff | Staff Software Engineer, Applications PreSonus Software Fender Musical Instruments GmbH
This is somewhat related to but not quite the same as https://github.com/robbert-vdh/yabridge/issues/411#issuecomment-2745339309. Studio One has their own VST3 extension for GUIs on Wayland so point 3 and 4 from that list are somewhat solved, but this would still require Wine's Wayland driver to mature and Wine would need to support embedding its Wayland surfaces in other applications. The alternative would be to build a custom compositor and to use XWayland directly (which is somewhat similar to what gamescope is doing), but that sounds like a massive amount of effort. While still a huge endeavor, doing the same thing on Studio One's side sounds like it could be a better use of time since that would unlock the entire existing catalog of Linux VST3 plugins without requiring every individual plugin to implement a third party extension.
While still a huge endeavor, doing the same thing on Studio One's side sounds like it could be a better use of time
I can't talk about Studio One features here. Feel free to issue feature requests at https://feedback-software.presonus.com/ though.
I'm personally more interested in a future-proof solution using Wayland only instead of having to rely on compatibility layers forever.
Regarding your points from #411 :
The embedding story for Wayland needs to be fleshed out. The XDG foreign protocol seems to have stabilized, but I have no idea how usable that is.
xdg-foreign solves a different problem. Embedding foreign views in a host window can be done by using subsurfaces and a custom compositor implemented in the host. This is what we did. Studio One acts as a Wayland compositor which the plug-in can connect to using the IWaylandHost interface.
Wine would then also need to add support for embedding on Wayland using this protocol.
Not sure if explicit support for embedding is required. What's required is support for creating child windows using a wl_surface parent created outside of Wine.
As far as I can tell, Wine already supports creating Wayland-backed windows with no surface role attached. See https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winewayland.drv/window.c?ref_type=heads#L200 Maybe one could create such a window, get the wl_surface pointer of this window (not sure if this is currently possible) and make it a subsurface using standard wayland calls, using the parent surface returned by IWaylandFrame::getWaylandSurface.
What might also be missing is a way to make Wine use the correct wl_display (the one returned by IWaylandHost::openWaylandConnection). See https://github.com/cclsoftware/wayland-server-delegate/blob/main/source/waylandserver.cpp#L199 for the current host-side implementation.
If using an existing wl_display is not feasible, we could think about adding interface methods which create a socket but don't create a wl_display yet. Wine could then be initialized with the environment variable WAYLAND_SOCKET set to this socket. See https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-client.c#L1337
The plugin standards need to agree on a way embedding on Wayland works, that is also compatible with what Wine supports.
There is no standard yet, but a proposal (which might be even better, as we can still change things).
Hosts need to create native Wayland windows and implement support for this new Wayland embedding protocol. This would mean either dropping support for X11, or maintaining two incompatible window implementations, neither of which sounds like a great idea.
Studio One is a pure Wayland application. Other applications using toolkits like Qt or GTK might be able to switch to Wayland without too much effort as well.
And then finally once all of this done, yabridge would need to be updated to act as a bridge.
Right :)
@jwolffpsl
Thanks for your input. I can understand the desire to look forward.
This is from a user perspective and it's probably not applicable to your responsibilities but maybe it will be useful to someone working on Studio One.
I don't mean this harshly, because there are no compatibility layers Studio One is currently useless to me. I can't take my workflow into Studio One: none of my instruments work, none of my effects work. By putting the onus on plugin developers this situation seems likely to continue. Then, potentially, Studio One exits the Linux market on the next version because there's little uptake.
If you can get your wayland layer into VSTGUI, Clap, LV2 and JUCE so that whenever someone does a Linux build it will work automatically, then that opens up a good subset of plugins. All of these projects seem to have way more X focused code.
If you can aid @robbert-vdh with patches to yabridge and wine with patches to their wayland backend that opens up way more plugins.
In the end there will still be many plugins that don't work but the problem will diminish over time.
The other alternative is to provide a way for X based plugins to work.
I'm sure that when Presonus decided to launch in the Linux market and to go Wayland it was very much forward looking. With a market share of what maybe 5% judging by plugin developers I've spoken to, you'd have to assume that it's going to expand, but there are also Linux options that work with my plugins: Bitwig, Reaper and Mixbus/Ardour etc.
I have around 1157 windows based plugins and 153 linux based plugins. I regularly use maybe 50-60 windows based plugins and around 30 linux based plugins. If I can't use Fabfilter, Spitfire, u-he, Audio Modelling plugins, I definitely can't use a DAW and there are a plenty of other manufacturers whose plugins I use regularly enough for it to be a major workflow problem to not be able to use them.
This is not a fake. Studio One 7 Linux and EZDrummer 3 (Windows VSTi).
https://youtu.be/OEifUIpxz8E
I will make a video how I did it soon. But don't get excited, it's some kind of a workaround... but it works.
