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.