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.