@amadeus You need to statically link plugins to not rely on any external resources. Sadly JUCE changed the default to dynamic link when Jules left...
As for flatpak. Nobody should distribute plugins in that format, it's not just technically wrong (sandboxing DSP) but also violates all plugin standards out there.
We finally got fixed system wide locations standardized (thanks VST3, CLAP, LV2), only for flatpak to come along and ruin it.
@amadeus thanks for the initiative!
reminds me of https://xkcd.com/386/ 😅
@amadeus that sounds like they just need to "lazy load" libcurl instead of linking to it.
JUCE supports this for example https://github.com/juce-framework/JUCE/blob/develop/modules/juce_core/juce_core.h#L155
But not all developers even know it's an option. 🤷
@amadeus I do not know, I only heard some some birds that the latest Push 3 is powered by Linux and has Ableton code inside.
So it is technically "Ableton Live on Linux".
Most likely it comes down to support. Many companies use libraries/frameworks that already support Linux. But these companies have no experience with Linux and don't think the expense is justified.
I have seen Linux builds that do run, but due to support costs companies prefer to keep it at macOS + Windows only.
@amadeus by the way there are several issues regarding the licenses of the frameworks, critical ones at that.
LV2 is liberally licensed https://gitlab.com/lv2/lv2/-/blob/main/COPYING
It is not under GPL as the page states, please correct it.
Also VST3 SDK is not free for non-commercial. it is GPLv3+ alike JUCE where you can use it on GPL projects but proprietary software needs a license. (*)
Anyone can make a commercial + open-source VST3 plugin, no limitations there.
* VST3 has a GPL-incompatible clause
@falktx I added open source labels now but need to go through the list again to make sure I catched all of the OS developers. Thanks again for the suggestion! 🙌
@amadeus I think it matters for developers seeing the site, as it means there is source code that can be used/seen as reference.
By that I mean, if a developer sees an issue with their Linux builds but some other random plugin X does not have those issues, seeing that X plugin as opensource is very helpful as then its source code can be studied to understand what it is doing differently.
It also helps in the case of "how do I do X and Y on Linux?" if other devs did it before
@amadeus for this "DISTRHO" would be the vendor, the name doesnt mean anything it was just a typo that stuck.
DPF stands for "DISTRHO Plugin Framework".
mobile platforms are not supported. I honestly never bothered to even try
@amadeus all platforms, including those that other platforms typically dont care about - like BSD and Web/wasm. It should work on any regular Linux/Unix/Posix-like system with X11. Very little code there is Linux specific.
Someday the GUI side will work on HaikuOS too, but not really rushing for that.
@amadeus wait maybe I misuderstood, do you only want to showcase "commercial" plugins there?
I would be sad if so.
If someone does everything else the "commercial" counterparts do - pre-compiled binaries, project website/homepage etc does it really make a difference?
I don't like to put a price on the things I do regarding software, don't want to start now.
@amadeus DISTRHO is missing from the list, which has, among other things, Cardinal and Ildaeil.
https://github.com/DISTRHO/DPF/ could be shown as alternative to JUCE.
It is what pretty much all my plugins use.
I guess this means I really need to make my projects more visible...
Sonoj Convention 2025 – Oct 18–19, Cologne 🇩🇪 Independent event for those who create music and sound with computers—whether recording real instruments or working with digital tools. Visitor registration open, contributions for talks & concert / open mic welcome! 🎵 https://sonoj.org/convention #music #audio #opensource
@texec less than 10ms was the target.
with this change the device-induced latency is around 5.5ms, then any extra for block-size buffers (so e.g. 2.6ms for 128 frames / 48kHz)
For the curious ones, kernel diff https://github.com/Darkglass-Electronics/radxa-kernel/commit/1c99fb0a7788811a4eb212c3c0bdcb64dc9d955f
and user-space side https://github.com/falkTX/audio-bridge/blob/main/src/audio-device-impl-linux-mmap.cpp
The things we do for a few milliseconds of latency...
Like today, patching the Linux kernel to create a memory-mapped buffer that both the kernel and a JACK client can use at the same time.
(the previous/mainline code was using an alsa virtual device to expose the audio data)
Reduced latency of the "task" by around 20ms ✨
Now just need to deal with ARM memory barriers and other details to ensure a good sync, I think...
@PaulDavisTheFirst the linux embed device as a usb device, aka "gadget".
This little Anagram can be used as a USB2 class-compliant audio card.
All the tuning and patching to get this feature to work just right is giving me headaches though 😭
My workshop on #Ardour #Lua Scripting was accepted at the #linuxaudio conference.
Come join me in Marie Curie Library in Lyon on June 26th, 17h
Registration is free: https://jimlac25.inria.fr/register/#register-to-lac-25
PS. There will be macarons :)