VCV versus the real thing: some thoughts

OK, in starting here, I'd like to point out that I haven't upgraded to VCV 0.6.x. There are reasons for this which should be apparent as I go on.

There's been a sizable amount of hype around VCV Rack being a be-all/end-all open source Eurorack emulation system. In theory, the idea seems like a good one, allowing users to experience the concepts behind modular programming in a very cost-effective way. And in a real sense, this is a very good use for VCV Rack. It's a nice set of...ah...introductory tools. But getting beyond that, there's some very real problems.

VCV's developers would like us to think that their creation is a just-as-valid item as the hardware. And this is where I part company with their aims and goals. As I've worked with the system, starting in 0.3.x and moving up to the final 0.5.x iteration, a lot of very irritating points have made their presence known, ones which are very much NOT part of the actual hardware modular experience. So, let's have a look at these:

1) VCV Rack is not a pro-grade tool. This shouldn't be too surprising at this point, especially noting the 'working-beta' status of the software. But even beyond that, there are issues with VCV that I've encountered that rise above simple beta-era growing pains. One of these is the automatic breaking of ALL modules upon each new iteration of the software. No, I kid you not. Every time a new beta appears, every plug-in developer is required to scamper back to the drawing board and recode their module sets for the new iteration. To me, this is the most egregious part of the unprofessional aspect. Consider what would happen to software plugin development if, every time a new version of the VST standard appeared via Steinberg, ALL plug-in developers would be faced with a scenario without backward compatibility. It would certainly stifle development, and moreso, stifle the value of the format. Do that, and the money goes away, then the platform falls flat on its face. In a professional-user environment, this sort of thing is totally untenable.

There's also no basic standardization of how the OS should work. Some knobs work one way, others in some other method, so you have to keep what works how memorized as you're also trying to do music. This eventually becomes a point of frustration and I for one don't appreciate being made to feel frustrated by the very tool I'm trying to create with. Certainly, this comes from the open source concept's somewhat anarchic way of dealing with its plugin developers...but at the same time, it's extremely annoying for those who don't see any functionality in allowing this degree of freedom in emulating a hardware environment where, yes, knobs work the same way, switches all perform the same way, and you can intuitively grab any of these and work them without having to remember how to turn or switch them.

These are just a couple of points. There's a lot more that I and I'm sure others have run across, and that list just gets too long to slap up here.

2) VCV Rack's developer seems to have a disconnect with its end-users. I encountered an issue in 0.5.x where the process I was working on was bogging as I added sampling modules, gradually wrecking all of the patch's internal timing. I examined what was happening, and quickly noticed that VCV wasn't multiprocessor-savvy; all of the work was being done on just one of my multitrack machine's 16 cores. leaving the rest to just idle while one single Xeon core was repeatedly being taxed beyond its limits. So, I did the logical thing one would do with open source software: I got on GitHub, searched amongst the loads of issues and bug reports, found little-to-nothing on what I was encountering after 45 minutes of searching, then posted about what I was running across, also inquiring about the possibility of multiprocessor support at some point down the line. What I got back was a rather prickly, snarky email from the developer that my thread was closed as my issue had already been raised (somewhere), then noting that multiprocessor support wasn't some idly-addable feature that, clearly, 'laypersons' woudn't understand the requirements of.

Ummmm...excuse me? Are you aware of who your user base is? It's not coders, for the most part, it's musicians. To dismiss the primary segment of a user base as 'laypersons' is not only rather tone-deaf, it seems to imply that VCV Rack isn't really about the musician end-users, but to satisfy some segment of the coder community. As such, that revelatory email cast a lot of doubts in my mind as to the long-term usability of VCV Rack; there didn't seem to be a sense that, once the application reached its initial full-release stage, the developer wouldn't move on to some other coding curiosity, basically orphaning VCV Rack in the process.

3) VCV Rack doesn't work like the actual thing. Yes, the module emulations are stellar for the most part. But it has a serious flaw in its single-core operation. It's sort of analogous to what happens when we hit power supply limits in hardware...but unlike hardware, you can't go out and get a bigger power supply. So when processor bogdown starts and things begin to go awry, there's basically no fix. None. You simply can't do what you'd envisioned, period, end of story. And for something that is to emulate simple builds, that's not a problem. But to do massive, complex work, you either need to have some sort of howling-fast CPU so that the sole working core for VCV can max it out...or you need multiprocessor support, which is the real answer, but one which isn't tenable from what I gather. And also, when VCV glitches, it's not pretty! Things we might find musically useful in hardware translate into hangs and freezes of all sorts of things, ranging from parts of a patch all the way up to the computer's entire OS. Hardware doesn't do that, either!

So, for those wanting to merely explore modular synthesis...yes, VCV Rack is a nice...toy, ultimately. But I'm totally put off of using it seriously, which I'd had high hopes of doing and, apparently, a lot of plugin developers would like to see as well. It won't replace hardware; I don't even find it to be an acceptable substitute.

I still have yet to get my first eurorack, but I have played around with most "modular" software and my favorite so far is Reaktor Blocks. Sure it is not emulating any eurorack modules, but I think it provides a professional-grade tool that is customizable and has some of the same spirit of eurorack. The best part is that you can use Reaktor to control and/or compliment a Eurorack setup.

In my opinion, VCV Rack is nice to get an idea of how a eurorack module works (provided there is an emulation of it) and could be a great option to explore new modules before actually commiting to them in your eurorack. But I would not use it as an actual musical instrument. Perhaps it'll get there one day, but that day is not today.

Agree with you guys here regarding VCV Rack, I tried to use it and it was flawed at best. Since I have NI Komplete and was trying the Reaktor blocks that is way more fun. Not rich enough to buy a full on Eurorack setup but think with Reaktor, Massive and my 0-coast that should tide me over for a while. It is sad how VCV Rack wasted its potential in reaching musicians.

I agree partially, have you red this interview with the developer? https://www.synthtopia.com/content/2018/01/22/open-source-synthesis-behind-the-scenes-with-vcv-rack-creator-andrew-belt/
The last update solved a lot of issues, it was the biggest update yet.
Some of the modules in there are not emulations but clones, exactly coded like the hardware like for instance the texture synth (Clouds).
I am in experimenting stage with VCV but I like the potency of it. Like you can use your midi controllers easily within it and therefor within my harware rack also. And also using multiple audio interfaces I find appealing.

Time will tell if it is here to stay but because I am on a limited budged I'm very interested in a hybrid setup with it.

Yes, I have...however, the fact still remains that VCV doesn't have the ability to fully utilize the given resources in a typical pro-level DAW machine. Once you've hit the limit on the one core it's using, you're done. Period. While this might not be as severe an issue in a quad-core Intel running at a fast clock speed, if you're working with a major multicore setup for the sort of brute force it offers, VCV is pretty sad stuff when you start getting into sizable module counts, such as what you'd see with complex generative patching, etc. And I know quite a few pro-level users who've gone with the big multicore Xeon, etc setups because when you use something that is multicore-aware, that software becomes screamingly powerful and tends to outstrip quad-core much of the time.

Unless you run VCV. And with no clear indication if multiprocessing will ever be added (as is the case with pretty much ALL other pro-grade audio software), I'll stick with considering it to be a 'toy'.

One of these is the automatic breaking of ALL modules upon each new iteration of the software.

This is effectively solved with the build system designed at https://github.com/VCVRack/community. Since most modules are open-source, a breaking update to Rack's ABI just means re-running the automated build script and distributing updates to everyone via the Plugin Manager.

There are no software projects that solve the problem of API/ABI incompatibilities. Steinberg doesn't solve it either---they "solve" it by never releasing updates to the VST standard. You might say that VST is backward-compatible. No, every VST host has to implement the VST 2, 3, etc standard separately.

When Rack 1 is released, all 1.X plugins will be compatible with 1.Y. Rack 2 is many years down the road and will be like the migration from VST2 to VST3, except it will be automated for users and semi-automated for developers with help from the "VCV Community" project.

You are confusing Rack as a stable software package at this time. Two decades ago, "beta" meant early, unstable, in-the-works, experimental, and buggy. Now, some consumers think it's another name for a stable release. If you want professional, stable software, DO NOT use beta software.

There's also no basic standardization of how the OS should work. Some knobs work one way, others in some other method, so you have to keep what works how memorized as you're also trying to do music.

Fair point, and I don't like inconsistent knobs as a user, but if developers want their own unique look and feel, it would be against the grain of the flexibility and hackability of community software to stop them. Imagine if all websites looked the same. That would be great for me when I'm trying to read information, but no web developer would have the chance to attempt to stand out from the crowd, and regulating that seems counterproductive.

noting that multiprocessor support wasn't some idly-addable feature that, clearly, 'laypersons' woudn't understand the requirements of

Here's the thread https://github.com/VCVRack/Rack/issues/823 to your GitHub issue for reference. It's not snarky---it gives a good lay-person's reason for not supporting it at the time, and I linked the thread https://github.com/VCVRack/Rack/issues/195 which is a full discussion of the technical issue if you prefer that instead.

A bit of a mid-level explanation is that modules in Rack exist on a unidirectional graph with no specific graph-theoretic structure whatsoever. If you try to assign different modules to multiple threads, they'd need to synchronize upon each sample before continuing, and 1/44100 seconds is too short for this on non-realtime operating systems like Mac, Windows, and Linux. There are some tricks that might work in theory, which is discussed in the technical thread, but Rack would be the first to implement a solution to the general problem proposed there.

With that said, I imagine your wish is not actually to multithread Rack's engine thread, but to make it handle more modules. The bottleneck of Rack is not actually the stepping of its modules, but samplerate conversion, rasterizing SVG with OpenGL (specifically tessellation of curves), and DSP block operations in particular plugins. The only modules that need to be on different cores are the ones with block operations like FFTs or file encoding/decoding/IO, and they absolutely can do that, and there are some that already do.

I should point out that Native Instruments REAKTOR, Softube Modular, Puredata, and all other virtual modular synthesizers I'm aware of all do not multithread DSP either. It's not because it's a super difficult problem (although it isn't easy), but because it's not a huge problem after all. One core can do the serial DSP stepping, one core can draw the complex 2D UI, 7 cores can do asynchronous FFTs, 2 cores can run your DAW, etc.

Virtual modulars are different from DAWs because a multitrack DAW can be thought of as a one-level tree that processes 64-1024 sample blocks, so multithreading is much easier. Same goes for N-voice synth VST plugins.

VCV Rack doesn't work like the actual thing.

Rack wouldn't be possible without the hardware it was inspired by! Go out and support your nearest hardware modular manufacturer. But before beating the dead horse that hardware is better than software (we all know it), remember that there are millions of would-be musicians in the world that would give anything to play a musical instrument but are not financially able to express their creativity in the way they wish.

VCV Rack is already used by a few household names, live musicians (even I wouldn't recommend doing that right now, but I won't stop you), Hollywood film composers, and university professors, so while it might not fit into the industry standard rules of being a "professional audio application", professionals and amateurs both get use out of this "toy".

Very clarifying reply, what you can do outweights what you can not do.

A clarification: given that VCV is an open-source project with respect to the module developers, it's apt to fall victim to the open-source issues that tend to dictate that those developers don't necessarily coordinate their efforts on resource utilization amongst themselves. And this was where my issues were arising; adding certain modules, notably FFT-heavy ones, were causing glitches to appear in timing and control signals to the point that, eventually, the patch would either become unusable and/or VCV itself would crash. This could be avoided, to my way of thinking, in a couple of ways:

1) Establish clear resource-management standards amongst the module developers. This isn't unusual; Dieter Doepfer's de facto establishment of the hardware Eurorack standard early on, with clear form-factor and bus connection standardization being the goal, is one of the things that makes Eurorack work. And yes, there's been attempts to buck that, most notably Analogue Systems' adoption of a physical form-factor that wasn't in line with what other companies (piggybacking on Dieter's work, which was in turn based on existing process control hardware form factors) were doing at the time. Result: Analogue Systems makes some pretty hardware that doesn't see nearly the usage that it could, because it doesn't physically 'work'. Now, in a virtual device, the physical form factor issues are minimized, but processing resources become the 'elephant in the room' if several developers can't follow some sort of programming methodology that allows all modules to exist happily with the same resource utilization standard. And this was what seemed to be part of the issue I ran across; adding modules that were FFT-heavy with respect to their needs would bog all modules in a given patch, some worse than others. It strikes me that what has to be done, therefore, is to give developers a map they must stick to in terms of resource management, or to employ some sort of reallocation within VCV itself to force things to work more seamlessly. And knowing what I know about computing, the latter method seems as if it would be very wasteful and ultimately detrimental to the whole under the present circumstances.

2) Reconsider VCV's core. Yes, this gets into that last bit above, but if a very robust memory/process management routine set could be added that could do this fairly seamlessly, it would go quite a ways to solve issues of this sort. This would also be the logical point around which multiprocess/multithread support could be dealt with more effectively. VCV needs some way of becoming 'machine-aware', gauging what resources it has at its disposal, and then allocating those resources effectively to the myriad plugins. And no, I'm not under some illusion that this would be an easy task...in fact, I think it would be difficult on a number of levels...but it's an effort that would make the difference that could keep VCV around for many years, which is what I think we all would like to see. I'm not under an illusion that hardware is better than software, as each have their own strengths and weaknesses, but more that there's room for both, and if both can be the best they can, then they definitely should be. It's not, to my way of thinking, a situation where anyone should be saying "it has to be like this because...", but more one of "why can't it be that way, given enough effort?" Some of what you state above tells me that there are some solutions that don't get into the really headachy aspects of sample-rate sync et al, so it strikes me that taking steps to have VCV's core process do some sort of processing reallocation that dodges the nastier digital audio issues could be feasible. And any bump in 'horsepower' in the end would be worth the effort.

Yes, I do see this as a developer vs. user issue...but one in which there's potentially a lot of common ground that could be very fertile. After all, had Bob Moog not been listening to his musician userbase and, instead, approaching his hardware development strictly as an E.E exercise, we'd likely not be having this discussion right now. The inherent problem is that those of us who approach VCV from a purely musical standpoint are apt to run across issues due to working methodologies that diverge from what developers tend to see as issues of importance. But also, musicians can vote with their feet, so to speak. For example, I myself have a rabid hate for ProTools. For many iterations, it didn't work in a way that a composer like myself, making intuitive decisions and trying to think outside the box, could feel comfortable in. Then along comes Ableton Live...developed by musicians, basically. It does what PT can do, but a lot more, and its workflow functions in a more 'musicianly' manner (if that makes sense).

So, when coding a musical device such as VCV, approaching it from a bit of a less-rational standpoint might seem like a recipe for disaster from a coding standpoint...but it winds up becoming something that doesn't impose itself on how musicians tend to think. It's a very weird tightrope-walk...but an invaluable one.