drmr

And this transition is nowhere near done. Just look at Kicad and pretty much any DAW that loads audio plugins (to name two major usecases where Wayland simply doesn't cut it).

Sure Xwayland exists and mostly (not entirely) works, but that's a band-aid for what is essentially a "we broke it and don't care" approach.

Being critical is not the same as being anti.

If you're not allowed to be critical of a subject, then one should question if the subject has any true merit.

If you think that this project makes any money you are completely clueless.

Disingenuous how? it's a factual comparison list.

You say it's pointless to compare to VCV Rack Pro where the whole point of the Cardinal project is to create a plugin version.

I think your commentary is disingenuous.

The core differences are documented here: https://github.com/DISTRHO/Cardinal/blob/main/docs/DIFFERENC...

You can host Cardinal inside of Cardinal inside of ..

Exactly, you said "little set of features" but this is anything but little.

You can also use any VST plugin inside of Cardinal using the Carla and Ildaeil modules.

Any proprietary or GPL3.0-only modules would of course not be able to be built into the binary (also bit cheeky to consider those as "missing" since they are fundamentally incompatble). And this gives VCV Rack a better value proposition, so a reason for people to specifically use it.

We also have several modules that are missing from VCV Rack because they were never ported to 2.0 Some of our own modules are missing from the VCV Library because of their commercial restrictions.

And while the idea of an "infinite" rack of modules is really cool, that is also not the goal of Cardinal or how we feel it is best used. Quality of quantity first.

There is still a big list of potential modules to include: https://github.com/DISTRHO/Cardinal/wiki/Possible-modules-to... However we are somewhat limited by what we can even build in a single CI job on github. Our current builds are already quite stretching of what is possible. And again quality over quantity.

You can read about all the main differences in this document: https://github.com/DISTRHO/Cardinal/blob/main/docs/DIFFERENC...

One could argue that a plugin version is more than a minor feature.

Cardinal is not affiliated with VCV in any way. We use the upstream Rack source-code as a base so any support towards VCV will ultimately "trickle down" (in the form of code) back to Cardinal as well.

Cardinal does not load any external module binaries, the entire plugin is a single static binary. This is done on purpose for stability and resolving symbol conflicts within a single namespace. We believe this is the best way to operate an audio plugin.

There is an LV2/VST2/3/CLAP/JSFX plugin loader (Carla or Ildaeil) that can load audio plugins, but these don't sit directly in the Rack DSP graph and do not modify the Rack runtime like its modules do. You could load the VCV-Pro plugin and run it inside one of these if needed ;)

They are not necessarily "virtual analog", they can also just be "digital".

Think the Mutable Instruments modules, many of these are based around STM32 microcontrollers. The firmware is MIT licensed and has simply been ported into Rack modules.

There are a number of Rack modules that started out as pure hardware that now have virtual counter-parts.

These are proprietary so how would you include these?

Cardinal is based on open-source modules (compatible with GPL3.0-or-later license) that are all compiled into a single static binary.

This is not possible with proprietary binaries.

You think over 1200 modules is small?

Definitely enough for endless hours of modular patching.

What do you mean `trying to GPL VCV`? The Rack 2.0 project was always licensed `GPL3.0-or-later` so we are using it exactly as intended.

Cardinal also contains MIT, BSD and CC0 modules. As long as all the code is compatible to GPL3.0-or-later since everything is built into a single static binary.

A lot of work has gone into due diligence in order to vet all the resources that have gone into the project: https://github.com/DISTRHO/Cardinal/blob/main/docs/LICENSES....

The value proposition that Cardinal offers by being self-contained is one of stability, backwards-compatibility and being able to easily share patches with other users without having to download or buy anything additional.

See the differences document to better understand how the projects compare: https://github.com/DISTRHO/Cardinal/blob/main/docs/DIFFERENC...

We are using it to create a self-contained opensource plugin. How does this "undercut" VCV?

Their main model is based around having a "limitless" store where users can buy "premium" modules. And having a plugin-version that allows loading these dynamic modules. This is not something that Cardinal allows and goes straight into the philosophy of a "self-contained" audio plugin.

If anything it's an easy (and free) stepping-stone for users to try a plugin version of Rack and then buy "the real deal" when they want the full-on VCV Rack experience.

The two can easily co-exist. They can even load each other as plugins.

He is currently employed by MOD Audio (and is the lead developer for the MOD software stack). For the rest he gets some donations via github/patreon/etc, but not nearly enough to make a living.

Re 1: Why not create a DPF wrapper for this and have DPF create the ladspa/dssi/vst2/vst3/lv2 for you? -> https://github.com/DISTRHO/DPF

Oh, no. That's just the NON meta repository mirror (because Jonathan removed his repos from the internet).

The New-SM repo is hosted here: https://github.com/jackaudio/new-session-manager

Maybe rasengan can pull some funds out of his ass to host the server.

NSM is an API to launch and manage JACK audio applications to store connections and program state. NON is the "groupware" DAW project of Jonathan Moore Liles from which NSM originated.

Because I use Linux Pro Audio tools in my studio and daily life and am involved with testing builds, helping with ports, generally messing around (, break stuff), and occasionally make a tune or two.

I am very happy with the free and open tools I have at my disposal. Even with the numerous rough edges, duct-tape and hacks to keep some things together.

This is Hacker News, right?

Rebranding a fork is absolutely normal. not "filing the serial number off". You realize that all git commit history is kept? They are not "scrubbing" Jonathan's work.

Do you even know what NSM is?

Jonathan Moore Liles removed all NON repositories from the internet. Only backups and forks exist.

NSM can potentially be used with JACK on win and macos. It also works with JACK implementation of PipeWire for Linux.

I expect Linux audio to converge on PW (unifying alsa, jack, and pulse in the process).

Linux video has this split with Wayland which is a whole different problem (I want my fluxbox :/). PW originates as Pulse Video, and designed to work with gstreamer pipelines and wayland compositing. aiming for better userspace separation of hardware and applications. I really love the idea of having JACK, but then for video. (no more vloopback hacks, named pipes or random socket servers to bounce framebuffers between applications)

JACK will then live on for dedicated Pro Audio applications and hopefully on win and macos as the old-skool "this also works" audio API that really only a small niche uses (and can break at the snip of silicon valley's fingers).

NSM is an API to launch and manage JACK audio applications to store connections and program state. NON is the "groupware" DAW project of Jonathan Moore Liles from which NSM originated.

I find RaySession very reliable in my experience so far. And we have an awesome patchbay with grouped ports (stereo patching!)

The API is NSM, there is no difference between the two. 'New' is a fork of 'Non' implementation, but they are compatible.

Heck, now that Jonathan removed _all_ Non project repositories basically no longer exists. Only in the git history of the fork. At this point in time we do not have a Non-SM other than legacy packages and forked repositories, but the NSM API lives on.

The NSM design is sound, people are using it. Thank you Jonathan

Or maybe there is just a varied group of enthusiastic geeks that just want to collaborate on common tooling like APIs, libraries, frameworks, packaging, and distribution.

It may "seem" that there's some sort of "take-over", it's just that people are actually coordinating on these common goals of free software audio tools.

NSM is a decent session management API. Currently recommended for any kind of session management in PipeWire.

Unfortunate that JML imploded like this, his work is legendary and software elegant.

All smear campaigns aside it's really crap to see this continuing hostility. Free Software also means moving on after a conflict and learning from past mistakes, and fork when necessary. Not to throw a tantrum and destroy all your work.

Btw most NSM stuff works pretty good under PipeWire. RaySession is a nice tool for that: https://github.com/Houston4444/RaySession

I'd call it `FreeCV`.