Some context from a third party VCV Rack plugin developer:
> 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.
I cam across Aria's complaints about their experience as a developer within the Rack ecosystem, and I was very disappointed to read it. It made me reevaluate what I thought about Rack and Andrew's handling of the project.
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).
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.
It's unfortunate that my article, that was only meant to reach fellow module developers after my messages were deleted from the VCV community, was Streisanded and misinterpreted like that.
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.
As I said earlier, I was very disappointed to read of your experience as a Rack module developer (not least of the reasons: I use your modules often!)
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.
Thanks for that added context. I think it is a tricky situation but I guess the rights of the author would extend to them requesting that their name be removed from forks that they don’t agree with, including from the title. However, I don’t know if the author should be able to force you to change the title of a fork that they themselves didn’t make, whether they currently maintain the software or not. It is still accurate to say that it is a fork of a prior state of the project, even if it has since been modified. It gets into Ship of Theseus territory.
Wow. Thank you for bringing perspective, I wasn't aware of Aria's work (which is absolutely incredible) and of what's happening behind the scenes of VCV. It's very disappointing as the product is amazing and lowers the barrier to entry to the eurorack ecosystem.
VCV Rack has been featured a lot of times on HN (https://hn.algolia.com/?q=vcv+rack), and judging by the "2" in the submission title, I think OP wanted to highlight the new version that was just released, hence appropriate to link to the release logs instead.
> 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.
Since some people don’t like the cathedral development style VCV rack uses, I point people to a fork of an older version of VCV rack with two features VCV rack 2 doesn’t have:
* It can run as a VST plugin, so one can use it with their favorite digital audio workstation (DAW)
VCV Rack is such a wonderful piece of software. And I'm glad that eurorack manufacturers are using it as a bit of a testing ground too.
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.
I used to have >$3000 worth of modular and think VCV rack is great. It gets you completely into the modular world. Dipping toes is like saying pigments or vital is dipping your toes into synthesis. It's just jumping right into the ocean honestly.
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.
Definitely a great point. I think for a lot of people, the beauty in modular is in the letting go of the idea of a preset, and creating sound that lives today, but is gone tomorrow. For a long time, most of the music I made was very loop driven (also very quantized and static) — modular fixed that by rewiring my brain to work differently.
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)
Yeah for sure. That's the reason why I got into modular in the first place. Different workflow. It's just that the workflow ended up not working for me personally, but it definitely works for some people.
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.
So am I correct in concluding that you sold a bunch of your modular hardware and continue to use mainly software now? If so what software do you use besides VCV rack and what if any other (non-modular) hardware do you use
My setup slowly changes as the years progress but things are generally pretty simple. Right now the only hardware I have is a RME Babyface Pro FS, an arturia polybrute, an ableton push2, and Neumann KH310 monitors and the KH750 DSP subwoofer. In the past I've owned the Moog SUB37 CV and an endless list of eurorack hardware.
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.
Compressors are super important for character, groove, and general loudness - so that's mostly the reason why there's so much focus on compressors. Also since we are talking about hardware vs software, compressors are generally a hotly debated topic on that front.
I never understood why someone would go out of their way to get a specific compressor until I tried an LA-2A emulation. Once I heard that signature "squash" from the simulated opto-electrical circuit, it clicked.
Question for music folks (I've played with modular synths but only in a superficial, toying-around way): is this skeuomorphic paradigm really the best way to do this? With a physical system, running wires everywhere might be the only way to do it, but it seems like in software you have more options on how you manage to connect all your components together, and how those components are laid out on the screen. But since this tangle-of-wires design is popular, perhaps it really is the way to go?
I have experience with physical eurorack modular synths, visual sound programming tools (VCV rack, Max, audioweaver), and DSP programming (Supercollider, Matlab). I think the simulated wires paradigm IS the best one...for someone who doesn't want to learn at least programming and probably also matrix algebra. In my experience, sound code is generally a LOT of ugly boilerplate code surrounding a few really brilliant lines of code that require years of education to understand. But in a code-based version of VCV rack, the brilliant code would all be inside some object.
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.
You might be curious to check out Faust[0] which is a functional programming language specifically designed for audio dsp, sort of based on a simulated-wire structure.
Faust really operates at a much lower level than Rack. You could write a Rack module with Faust, but you wouldn't (probably) do the sorts of things you do in Rack in Faust.
I prefer it for synths that are very modular like these. There are other synths with just as deep a modulation capabilities and capabilities to route inputs and outputs and create feedback loops, etc. But the jumbled mess of cables is easier to follow than a big table of dropdowns, or a massive N x N matrix, or dynamic labels that appear over controls being modulated.
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).
I guess the design ethos of Rack is really to be a software-based Eurorack "simulation", and in that case, being fully skeuomorphic makes sense — you can't have eurorack without the rack system or the wires for CV/audio.
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.
There are essentially no dataflows within Live that model what happens in Rack. That's not true in some other DAWs, and is certainly not true in various other audio software. Consequently, Live's approach to "what you see" is just not an appropriate comparison here. It's different, but that's because it's really a completely different kind of workflow, not just "a different way of doing similar things".
This isn't just skeuomorphism as found in e.g. a VST plugin with a sci-fi UI or a patching language with a UI resembling studio-like effect chains. This is a simulator of a real implementation of modular patching (Eurorack), for example signals mimic real Volt scaling and the dark mode is like actually dimming your room lights. So, questions of how to "develop" in this mindset can also be directed to users of the actual hardware, who do not go through a computer UI.
In general, the wire tangle is an integral part of any signal-routing system, whether physical wires in hardware, a replication of those wires in software, or a less skeuomorphic box-and-pin model like Reaktor (which itself has a hardware-style layer with "cables" called Reaktor Blocks).
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.
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.
Fair; I get that if we're simulating a physical system and just trying to be as faithful as possible, the virtual one will look just like the physical one, and inherit its limitations.
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.
What do you think that Rack "tries to mimic [ from hardware ]" that Bitwig's grid does not? Are you just refering to the knobs etc.? If so, that's not in Rack's domain at all: module developers control their module's appearance, and there some which are extremely skeuomorphic, and some which are not. Bitwig's Grid is uniform and consistently non-skeuomorphic, but is also (IIUC) not open to 3rd party device/module development.
No, but there were already other software synthesis options available for people who don't want a skeuomorphic interface, as various levels of complexity - Max/MSP, PureData, Reaktor, CSound, SuperCollider, Audulus, KarmaFX, etc.
I find working with "modules and wires" interfaces that embrace digital more productive/fun but I can see the appeal. Two patching UIs that I really like are Audulus and Reaktor.
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, I found Audulus 3 much more intuitive when playing around (I have the iPad app). It was skeuomorphic in the sense that the components were little doodads you connect together, but, yeah, the patching and "space" was much more...softwareish?
To convey freeform "modularity" sends you in one of two directions: visual diagram notation of this sort, and source code "audio programming languages", eg Supercollider, which let you define things more symbolically/declaratively.
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.
With respect to why the developer of this particular developer went the way he did, he specifically wanted to give people the feeling of working with a modular synth. So while strictly speaking it may be "better" that was not the goal. The developer in particular has always been fascinated with the tactile experience.
Only a partial answer because I never get around to digging into it myself, but there is at least one other paradigm out there, "live coding", such as supercollider, csound, uh, more I'm sure.
I don’t mean to denigrate the VCV team, who do amazing work. I love everything but the UI, but I also understand it’s the UI they wanted. But even as a kid I couldn’t wait for patch cords to be replaced.
Wonderful to see this finally get released. A lot of people (myself included) have been awaiting with bated breath for 2 full years for VCV Rack 2.
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.
While what Andrew did in code is great, what I think has been even more impressive than that is to have created, sustained and nurtured a community, an API and an ecosystem that has in turn allowed hundreds of other people to construct the modules that actually make Rack what it is.
I'm not too jealous of the code accomplishments, but the ecosystem is a really strong envy point for me.
There should just be a standard for a software module, like VST for plug-in instruments. Then they could re-used across platforms, and a DAW like Ableton could theoretically host them directly without needing an intermediary VST host app like Rack.
I believe the new CLAP plugin format U-He and Bitwig have recently released is an attempt at this and a few other benefits plugins have been lacking for a while.
CLAP (like every other audio/MIDI plugin API) does not cover single-sample processing, which one of the core design ideas in Rack's module API.
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.
I know that each cable in VCV Rack imposes a 1-sample delay. However isn't the audio still transmitted to the audio interface in blocks? It's not clear why a DAW would need an intermediary in this case, other than something analogous to the VCV Rack 2 Pro VST instrument host. The reason not use Rack is so that it could be an open standard with multiple host implementations.
> It's not clear why a DAW would need an intermediary in this case, other than something analogous to the VCV Rack 2 Pro VST instrument host.
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".
My impression is that they view it as their product they are building and want full control. Community is useful for building plugins, but not to be given influence.
I'm curious about the pros/cons of Rack vs Reaktor. A Reddit comparison says VCV is better for modular by a mile, but not exactly why. Is it that it has a better library of modules? Or is more focused on emulating hardware modules than Reaktor is?
some context from a third party vcv rack developer, who has not yet left the scene.
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.
Cardinal is absolutely fantastic. It's advertised as a "work in progress" but already works really great. You can download frequent builds in Github actions / artifacts; they are available for almost all platforms.
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.
It is important to understand the reason for the limitation(s).
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.
The reasons given on the readme seem to be more technical than functional/practical:
> 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.
> 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:
https://news.ycombinator.com/item?id=27032669
[0] https://mirack.app/
[1] https://github.com/miRackModular