I think that people should understand what this represents, because I think most HN readers (let alone everyone else) won't get it.
1. Start from the Community Edition of VCV Rack (GPL licensed)
2. Redesign the fundamental architecture to match the way most other audio applications work with respect to interacting with audio hardware
3. Implement new modules to replace the most critical ones provided by the non-gratis VCV Rack Pro (plugin version), including sync with the host, exchange audio & MIDI with the host and more.
4. Create new GUIs for the Fundamental module collection that comes with VCV Rack, since those designs are not freely licensed, even though the modules are.
5. Identify VCV Rack modules licensed under "GPLv3 or later", and add them all to the build system, frequently requiring licensing clarification from module authors since the Rack world has been, uhm, a bit, uh, loosey-goosey with this.
6. Find or implement ports of the dependency stack for Rack to WASM
7. Port Rack itself to WASM, which requires a completely new audio/MIDI backend to deal with webaudio and webmidi.
8. Identify and fix browser-specific issues
It is a remarkable effort, and Filipe receives essentially nothing for what he has done.
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.
"Installing new modules on an existing Cardinal binary is not possible at run-time, but we can add new modules to the build."[1]
From the original release — being able to select 3rd-party plugins a la carte is probably Rack's most important feature, both for users and developers. Apparently there's a technical reason: "Cardinal is intentionally a fully self-contained plugin, Whatever is contained in the current build is what you can use"[2], but it seems like Rack Pro makes it work so I'm not sure why that's the case.
The reason isn't technical, it's because the author thinks a plugin shouldn't be able to modify itself on the fly.
I think he has a point. But besides, the modules included in Cardinal cover an incredible range; it's unlikely there's something one can't do with what's there.
The entirety of Surge XT has been pprted to VCV and is included in Cardinal for instance.
VCV Rack is quite fun and shows how the skeumorphic interface to things like music and synthesis is actually quite useful and understandable. While things like supercollider and pure data exist, it's hard to argue that VCV Rack's interface isn't a lot simpler to get going with.
I wish popular DAWs would learn a thing or two from it tbh. Connecting VSTs with the skeumorphic interface is a better experience than something like the otherwise excellent a Reaper does. Only FL Studio (with Patcher) gets this right.
Reason has racks and cables, if that's your thing.
Personnally, I like Reason's synths, but I don't find connectiong virtual cables on a screen super intuitive, or practical. After a while it's difficult to see what goes where.
Reaper is much less "sexy" but much clearer, IMHO.
Given the nature of that synth, there may not be a better way to do this, but it's still far from clear what does what at a glance, or even after staring at it for a while.
> skeumorphic interface to things like music and synthesis
There's a lot in Rack that isn't skeuomorphic. Really, a very big lot. In fact, even the patching process is only barely skeuomorphic - it doesn't obey the laws of physics in several different ways.
Reaper has no modular environment at all, so "connecting VSTs" is not really a thing in that context - the data flow is almost always linear.
Skeumorphic doesn't mean 1:1, it just means very much like it from a design perspective. Obviously, patch cables in real life aren't polyphonic.
> Reaper has no modular environment at all, so "connecting VSTs" is not really a thing in that context - the data flow is almost always linear.
It most certainly does. The VSTs that sit in the fx chains are the modules. Parallel fx chains in the same track are handled by a (quite terrible) pin based system. Then beyond that there's the usual sends and side chains.
1. Start from the Community Edition of VCV Rack (GPL licensed)
2. Redesign the fundamental architecture to match the way most other audio applications work with respect to interacting with audio hardware
3. Implement new modules to replace the most critical ones provided by the non-gratis VCV Rack Pro (plugin version), including sync with the host, exchange audio & MIDI with the host and more.
4. Create new GUIs for the Fundamental module collection that comes with VCV Rack, since those designs are not freely licensed, even though the modules are.
5. Identify VCV Rack modules licensed under "GPLv3 or later", and add them all to the build system, frequently requiring licensing clarification from module authors since the Rack world has been, uhm, a bit, uh, loosey-goosey with this.
6. Find or implement ports of the dependency stack for Rack to WASM
7. Port Rack itself to WASM, which requires a completely new audio/MIDI backend to deal with webaudio and webmidi.
8. Identify and fix browser-specific issues
It is a remarkable effort, and Filipe receives essentially nothing for what he has done.