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.
The daw problem is really really bad too. We've got a de facto standard forming right now where you link libwayland.so and hope the structs never ever ever change in the next 30 years.
It may be reasonable when you emulate a completely different platform but not when your are providing a compatibility feature in a supposed successor platform that can be designed to support that use case.
I can't find the benchmarks now, but the ones I recently saw on hacker news, xwayland was notably worse than either wayland native or xorg native. Bad enough to be noticeable by the average user.
Things like “Core only” vs. “Everything is internal” make perfect sense to me as a developer, but this doesn’t answer my question. In fact, “everything is internal” is a downside since no one really uses all modules.
It also appears outdated, since Rack 2 supports ARM (that’s how I use it).
It is also clearly disingenuous in quite a few places, such as by:
a) providing an uncritical generous excuse for every downside of its own (e.g., lack of multi-threaded engine), but never for VCV Rack’s (an opportunity to pay for an open-source project’s development so that it can sustain itself as a proper business is a feature that benefits both the project and OSS ecosystem as a whole), or
b) pointlessly comparing to VCV Rack Pro. I, like many, am not using any of the Pro features—just one of the amazing things about the base version of VCV Rack is its completeness, combined with generous licensing. The VCV Rack 2 I use is open-source, and is free (though I paid for Pro to support the project I don’t use any of the Pro features, I literally never needed them yet), and is supported (it receives updates regularly).
It is not factual as it is clearly biased in ways I described. It is also outdated and factually incorrect in ways I described. Feel free to address those ways specifically.
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.
Ah, thank you. The Plug-in version is one of the main selling points of VCV Pro though, no? I have VCV as a VST plug-in, plus the ability to use any VST plug-in inside VCV which were for me the main reasons to purchase it (apart from wanting to support the project and buy commercial modules).
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.
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 ;)
I'm not saying the quantity is small, I'm saying the subset is. There are 3,336 VCV modules. So, 1200 is only ~35%. Notably, for myself, only about 1/3 of the modules I have developed are there (some of mine are paid), and it lacks some of the truly great analog modeled modules such as those from Vult, Cytomics, and Lindenberg Research.
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.
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.
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.
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.