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.
It's indeed amazing. Do you know him personally? What does he do to earn a living? Does he do consulting on the side...?
In my (limited) experience he responds to issues almost immediately, and seems to be full-time on this; incredible.
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.
[1]https://kx.studio/News/?action=view&url=cardinal-2202-is-now... [2]https://github.com/DISTRHO/Cardinal/blob/main/docs/FAQ.md
Filipe has strong ideas on how a plugin ought to behave. You are free to disagree with him, but he puts in the work.
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.
Solution:
--------------- ---------------- | main thread | <--- SharedArrayBuffer ---> | AudioWorklet | --------------- ---load CPP WASM and postMsg ---> ----------------
I used to have that issue in my browser-based live coding env: https://glicol.org
But SAB makes it gone, except on old safari that does not support SAB...
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.
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.
> 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.
