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.
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)
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
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.
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.
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?
Readit News
> 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
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.
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.
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)
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.
[0]: https://faust.grame.fr/
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).
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.
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.
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.
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).
Dead Comment
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.
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.
Right now I'm polishing a hybrid system, with hardware Eurorack coming into Bespoke through multichannel audio.
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.