falktx @falktx@mastodon.falktx.com

@amadeus @linuxaudioplugindevelopment

> This means that if a DAW does not offer X11 support (...) it neither can be run on X11 nor will X11 plugins work inside such a DAW

This is false, the 2nd part.

A wayland-only application cannot run under X11
But! a native wayland application can 100% load X11 plugin UIs without trouble, assuming XWayland is present.
Try it! If you have Carla and Wayland, run "carla -platform wayland" (ignore project file warning)

If the host calls into X11, it works

@amadeus @linuxaudioplugindevelopment yeah that is not quite correct...

> X11 applications and plugins work flawlessly on Wayland

add a "mostly flawlessly". the compatibility is not 100%, there are cases where it breaks.

> none of the popular plugin frameworks support Wayland directly

true-ish, not officially yet, but best to say its WIP. I am working on it for DPF and JUCE has unofficial implementation https://forum.juce.com/t/wayland-implementation-for-juce/66840/

(more on next message)

@pluto Bitwig does that, kinda. The engine is its own process and plugins go together with it, separate from the UI and session manager. This allows to protect against engine/plugin crashes. It's not really sandboxing though.

For true sandboxing flathub with audio plugins kinda does that right now, by loading plugins within that same sandbox. But it's quite inconvenient, apps from flathub do not see global/system-wide installed plugins (and if they do they break sandbox rules)

@pluto haha, I have bad news for you...

99% of DAWs and audio plugin hosts do no sandboxing or bridging.

But it's kinda expected, when we are dealing with 1000s of plugins that need to run in less than 0.5ms each. Dealing with context switching and thread sync across these many instances would waste time that could be better spent processing more plugins.

@valpackett why complicate things? my idea is just to use subsurfaces

my tests on https://github.com/falkTX/wayland-audio-plugin-test show its possible and works.

but now begins the long process of turning hacky tests into usable things.

Yay for audio plugins under Wayland.

Non-embedded type for now, but one step at a time we will get there.

Also, today I answered a question I had for a long time...
If an X11 host running under XWayland calls Wayland-native APIs manually, would it be able to load Wayland-UI based plugins?
The answer is yes - Carla running under Qt xcb "platform" can still show Wayland UIs.

The reverse is also true (Qt wayland "platform" with X11 UIs through XWayland)

Future is bright 🌄

Wayland and audio plugins... it's possible! 📸

@amadeus also note that pugl (used by DPF and a few others) kinda already supports wayland, the code is "just" not public yet because it is also not ready and we need host support first

I think next year we will have our first LV2 wayland UIs, loadable within at least Carla and Qtractor.

@macberg yes as I see it incompetence can happen equality on both sides. stuff that leads to hacks by accident.

malice is harder to do when the code is open though.

also, proprietary + commercial vendors much more often have analytics and other network related features vs opensource plugins, so I am then more skeptical of them in general. a plugin requiring libcurl is often a red flag for me.

@amadeus I wouldnt be so sure...

My tests on https://github.com/falkTX/wayland-audio-plugin-test/ show it is possible, and based on that I could easily support wayland UIs in Carla (not the S1 spec though, please let's not do their proposal as it would complicate hosts job way too much)

afaik that repo contains the very first LV2 UI under wayland. granted it does nothing useful, but it does load with its own custom LV2 UI type

Audio production on Linux, using proprietary audio plugins, is somewhat funny/interesting to see in the context of security.

I mean, there are a lot of recent efforts to put applications in containers, sandboxes, lots of talking about X11 being unsafe vs Wayland...

And then users just download and run arbitrary binary code from the internet 😅

Nothing against those that do this, it is just a bit funny to see from a security perspective.

@amadeus hmm https://forum.babyaud.io/tos

> [INSERT LAST UPDATE DATE HERE]

I guess their forums are new?

@nielso @krullebolle feels like a feature implemented "because we can", without ever asking what users would want.

1 step forward, 3 steps back.

I am glad Debian still goes through the trouble of packaging web browsers the usual way

errr the "snap" versions of Firefox and Chrom(ium) still do not have WebMIDI support 😔

Glad to have an alternative Debian Trixie set up already, WebMIDI works nicely there!

It has been years though, so I guess nobody cares enough, or noticed...

So this is possible... web-browser based audio processing as part of your signal chain.

PipeWire makes this extremely easy to setup, and Ildaeil on the browser with some pre-compiled plugins makes the magic possible.

So here output from Firefox goes into Chromium to give it some LV2 reverb, then into some native metering plugin, then to the speakers 😆

Feel free to try this at https://ildaeil.kx.studio/
But ***beware of feedback loop when enabling input***
The browser will use default input!

Made a whole new plugin in just a few hours today 🎉

https://github.com/Darkglass-Electronics/anagram-midi-control

It would actually be < 1 hour if I didn't have to fix a few things on the framework first.

It's not really useful for users at all in general, this is just a testing tool for the Darkglass Anagram unit.

But I like to do things openly and there are no secrets on this one - all it does is send out MIDI - so why not have it open?

@unfa errr what?

> The plugins here are for sale on the site www.bluelab-plugins.com So please do not build them and put the builds online.

They can ask, but feels against the GPL. why are they opensource then?