Rack 2 (Virtual Eurorack)
github.com
github.com
> The last straw concerned the policy about taking over inactive modules. About making it possible by default for someone to take over my very name, Aria Salvatrice, and releasing their own fork of my software under my name.
> That’s right: if I’m inactive for just one short little month, someone else can just go ahead and release software under my name, my name as a person, with no process in place for me to reclaim it later, even if their releases have low quality standards, even if they add ill-conceived features that work against my long-term plans.
> It would be easier to continue my work if there existed a healthier fork to migrate to, but VCV has been trying to prevent forks both through legal and social means, so there’s no viable fork yet.
> There’s MiRack[0][1], a fork of VCV for Mac OS and iPhone. Any mention of it within the VCV community is immediately deleted, and its author is banned, so it exists completely disconnected from the VCV community, despite offering a smaller selection of the same modules with mobile support, which is something the community really wanted badly. Being only for Apple devices makes it impractical for me to use, so moving my development to it isn’t an option, unfortunately, if it were on PC I might have done that.
https://aria.dog/barks/why-i-will-never-create-modules-for-v...
Discussed on HN:
However, somebody then gave me a link to what is apparently one of the main threads [0] in which they and Andrew Belt's main developer "got into it", and after reading that I was much less certain about who was behaving badly here (if anyone).
[0] https://community.vcvrack.com/t/do-open-source-plugins-need-...
Regarding the MiRack fork ... I am not certain, but I suspect that this author acted in specific ways that upset Andrew. I talk regularly to the developer of Cardinal (mentioned below), which is another fork of Rack, and thus far, things between them and Andrew have remained reasonably cordial.
Certainly as the developer of another open source audio project, if someone behaved the way the MiRack developer seems to have done [1], I would likely seek to exclude them from our community too.
[1] I stress the seems because it really is not entirely clear what took place.
Most of us who have quit have not quit due to one incident, but due to a pattern of behavior over months. The incident you are bringing up was just the last straw. And what you are linking to is only what remains of the incident, as posts are often deleted, and disagreeing with moderation goes against VCV's code of conduct. Please do not assume you can read the archives of any incident and see an honest account of the full chronology.
The last time my article showed up on HN, a few people complained that my "product announcement" was too long and confused. Had I known it'd be on HN, I would never have mentioned what I was up to, as I have nothing to sell. I operate in an entirely different way than HN startup culture. These are passion projects done on my own time, and passion is fickle. Writing about my experiences was in part about making my peace with half a year of lost creative drive about music hacking. The audience was meant to be the dozen of fellow third-party developers who were fed up with coping with hostility and impostor syndrome.
However, this is a bit of a problem:
> Please do not assume you can read the archives of any incident and see an honest account of the full chronology.
The fact that Belt's handling of the module developer community has gained some notoriety that cannot be evaluated by reading "the full chronology" makes it extremely hard for those of us not involved in the original exchanges to make any confident assessment of what has taken place.
At this point, to be honest, the reading around of various threads (edited as they may be) related to all this left me with this as my only conclusion: your own personal style and beliefs and andrew belt's are deeply incompatible and it is probably best for everyone that you've chosen other pathways (you seemed deeply and personally hurt, and I could pretty much guarantee that it would happen again). I felt sympathy for both of your positions (at least as far as I could read them), and saw them as mostly irreconcilable.
I'm open to having my mind changed in the future. Your experience has certainly made me wonder if and how often I ever acted in a similar way that you feel Belt did, within the community of Ardour developers. I can remember only one (recent) incident in which someone felt they deserved explicit recognition for their part in a process. I hope that's the extent of it.
In a place like this, I'd rather see the source code as the headline link, rather than a press release, but the press release is still valuable.
> I don't understand the impulse on HN to make everything as technical as possible.
Well, it is called "Hacker News" and hackers tend to be technical, kind of makes sense.
* It can run as a VST plugin, so one can use it with their favorite digital audio workstation (DAW)
* The code is BSD licensed
Here is that VST plugin fork: https://github.com/bsp2/VeeSeeVSTRack#downloads
Lots of people are priced out of hardware modular synthesis, so getting Rack is a solid way to dip ones toes into that world. I'm unaffiliated, but highly recommend Rack if you're curious about modular.
Hardware generally slows down my workflow to a crawl. There's no beating the convenience of bouncing digital instruments. Especially for sound design. If you want a new sound with modular hardware and want to reuse your modules, you're getting rid of your existing patch. There's nothing more limiting than feeling like you can't use your gear because the patch it's currently configured for is too good to change. That works for some people but not for me.
Software most frequently used: All the stuff that comes bundled in with Ableton Live Suite (their plugins are amazing, don't sleep on it - just because it comes w/ your DAW doesn't mean it sucks), Arturia pigments, Vital (also free, better than serum in my opinion), u-he Diva.
For compressors I'm really using Ableton's stock compressor and glue compressor mostly but reach for DMG TrackComp a lot. Fabfilter Saturn2 for saturation.
I highly recommend this video if you're interested in why compression matters so much https://www.youtube.com/watch?v=K0XGXz6SHco
I don't think I'll ever go hardware only. The flexibility of software is just too good. But modular in general flexes different muscles for me, and I like that a lot.
(great username, btw. Been a Live user since version 1)
There's also something about for me about being more musical if I have physical knobs to play with that are mapped to every parameter available. This is largely an unsolved problem in virtual instruments. Nobody has really made a digital controller that maps nicely to virtual instruments, and I suspect the reason is it's because the plugin makers refuse to follow a standard to map out their parameters in a consistent way. There's work being done around some of this w/ Omnisphere and its ability to take advantage of your pre-existing hardware to map to all the virtual knobs, but I'd like to have a controller in front of me that consistently controls all of my virtual instruments in a way that makes sense and it mostly can't or doesn't exist.
That said, in general, what you see in software is a lot different. Mentioned elsewhere in this thread is Ableton Live (that has been around for many years) and is a DAW with a very clear design language that is all about the workflow and quite far from any real world device. But that's not to say that either approach is right/wrong - they both work.
Some examples: Bitwig's Grid (https://www.bitwig.com/the-grid/) and Patcher in FL Studio (https://www.image-line.com/fl-studio-learning/fl-studio-onli...). Afaik there is no equivalent in Ableton which I really miss sometimes (unless you consider Max4Live which is on a different level of usability).
But also part of the whole thing with modular synthesizers is you use whatever modules you want. As few as you want, or as many as your CPU can handle (or more if you're willing to ditch realtime).
So you would need a UI paradigm that can work for 2 modules with a couple inputs and outputs each, but also with a massive rack of hundreds of modules with up to dozen of inputs and outputs each. Do I want my fifth VCO to plug into input 3 of my fourth VCA? I'd rather just follow a cable visually.
Some synths do have a great UI that works for them. Razor and the original Massive are still among my favorite UI's for usability. But they're also more limited in their scope. (Yeah Massive is a really complex synth and could be your only synth for life, but true modular emulation style synths have an infinitely higher ceiling of possibilities).
You're essentially dealing with connected one-directional graphs of arbitrary complexity. Feedback loops are required for the eurorack experience. That's pretty easy to lay out visually, but I haven't seen good ways of laying it out in code. There's room for innovation here; Someone in the programming world has a more intuitive, more informative way of visualizing data in a graph that could be adapted into DAW paradigms.
I like the panel/patching split in reaktor, but it‘s an extra abstraction. They added "front panel patching" after all, so it must be more appealing to some people.. Audulus with it‘s parameters+patching on one level but no skeumorphism is at the other side of the spectrum.
Right now I'm polishing a hybrid system, with hardware Eurorack coming into Bespoke through multichannel audio.
What is "this" for you?
For me it is a cheap intro/evaluation tool for the very expensive Eurorack hobby. To meet that goal it must be skeuomorphic. I can mess around with VCV + maybe a cheap (relatively) midi control to get some physicality. To discover my interest is superficial and lasts only a few months. Saving me from thousands of dollars of more "toys" that just sit on shelf.
But I guess by "this" I mean "making the sounds I want to make". If I'm interested in composing modular software components into a synth without regard to its physical analog, a wider range of designs is available for how "composition" or even "component" are reified. But the patch-cables-between-2d-boxes paradigm still seems dominant in that domain too, from my casual browsing of it.
The one drawback I find to replicating hardware, as VCV Rack does, versus something originating in the digital realm, is that more complex modules bring over their hardware-based UI compromises.
An example of this is the Plaits module from Mutable Instruments, called "Macro Oscillator 2" in VCV Rack. The hardware Plaits module is very compact, and uses a series of LEDs with little icons next to them to denote which DSP algorithm it's running. The only way to know what anything does is to look up that icon in the manual and read what each of the knobs do in that mode.
In a software-first paradigm, the UI would use a software UI pattern rather than a hardware one, most likely a drop-down menu instead of a row of icons, and the labels on the knobs would change based on the mode (this is actually how a port I'm working on of Plaits to the Reason environment is designed).
All that said, many modules in VCV Rack are quite simple and would be no different if they originated in software. Things like basic oscillators, envelope generators, and filters need no manual diving if you understand the fundamentals.
To simplify this interface you have to relax the assumption that you will create a graph with arbitrary feedback loops: then your signal path can be acyclic or linear. Most things you will want to do in sound design use feedback in a very limited sense(e.g. a delay line effect) and can be turned into black boxes for a linear chain. Linear by itself is slightly too little power since you do want to mix and split signals at various points, and most commercial synthesizers use a "semi-modular" design that assumes a linear default and then adds particular methods of choosing modulation input at various points.
Regardless, modular's power to do anything is tempting to dive into. It's just a case of "not worth the effort" most of the time since having any input anywhere creates multitudes of obscure ways to get no output.
It impresses me to this day that Andrew Belt is the sole developer on the project. He's been able to do something tremendous in a relatively short amount of time for just one guy.
I'm not too jealous of the code accomplishments, but the ecosystem is a really strong envy point for me.
And as an aside, CLAP has almost nothing in it that LV2 didn't already offer, and nothing that could not have been added to LV2 using the extension mechanism, but a rather severe case of NIH pushed things in the direction that they eventually went. It's quite unfortunate.
Rack performs single-sample processing. DAWs (all of them) use block-structured processing.
For a DAW to host modules that are designed for single-sample processing would always require an intermediary. It might as well be Rack.
Because the modules are written to do single sample processing, which creates some design imperatives that are quite different from those used by regular audio plugin APIs where blocks of samples are passed around.
"But, " you may say, " isn't single sample processing just passing around blocks of samples with a size == 1?"
Well, sure, technically that's true, but you don't write code the same way if you know that the size is always 1.
Ergo, you're going to need something to execute the modules in a single-sample style, not block structured. That intermediate will be functionally identical to Rack.
Rack's API is completely open source, and anybody else could reimplement it. It would be horrible as a general audio plugin API, but it's pretty good for "rack modules".
while I agree with Aria's assessments[0], and respect Aria; their unhappiness is only focused on the founder (Andrew). I respect what Andrew has built, but unfortunately, the environment that he fostered has sprung up others that are 100x more toxic than Andrew himself on his worst days.
Unfortunately, there are others that actively attack every other developer and module in the ecosystem, constantly claiming that theirs are the only "good" modules (while claiming they've left behind rack completely). it makes for an extremely toxic environment that has driven many more away.
I think that until there are enforced community standards, it will just get worse, and drive more talented developers away. I know that I don't bother participating in the Facebook groups, reddit, discord, or the "official" rack forum because of these people.
so, for those who have emailed and asked why my modules aren't yet ported: they have been lower priority compared to other things, given the extremely toxic people in the community who make it really frustrating to build anything, since there will be immediate attacks for anything new by extremely toxic individuals.
[0] https://aria.dog/barks/why-i-will-never-create-modules-for-v...
I'll try to checkout the standalone later .
The limitation is it comes with its own modules (most open source modules available for VCV) and you can't load external modules. But it's already super powerful. Highly recommended.
Cardinal is intended to be usable just like a conventional plugin, which includes having presets that can be exchanged between computers (or even between users).
If Cardinal allowed arbitrary modules to be loaded, there's no guarantee that when the preset was used on a different computer or by a different user it would work, because modules could be missing. One idea for Cardinal is to be able to build "synths" with it, and then represent the result as a preset that could be used anywhere.
The regular Rack plugin version doesn't have this as an explicit goal, and therefore it can allow arbitrary modules to be loaded. You can certainly have presets, but there's no way to ensure that any context in which you use the presets have all the required modules.
> A proper audio plugin should be self-contained as much as possible, as to not interfere with the DAW/Host. (...) A self-contained plugin can't be overstated, as DLL/shared-object symbol conflicts can trigger hard-to-debug crashes.
I'm fine with the limitations, and like the idea of a self-contained plugin that does not phone home. And in my experience, Cardinal is already very solid and feature-complete, even in its beta form.
But one could absolutely imagine a system where you can share setups that use modules that may or may not be available. For instance, you can build, save and share combinators in Reason that use non-standard REs.
I'll try this tonight