ModularGrid uses so-called cookies to ensure it's so-called functionality. We also use dubious tracking scripts. Find out more in the Privacy Policy. We use cookies and wanna let you know.
Thanks to the ModularGrid developers, you can now go directly to the virtual VCV Rack version of a module if it exists by clicking "Available for VCV Rack" on the sidebar of a ModularGrid page. Example: https://www.modulargrid.net/e/mutable-instruments-plaits
So far there are about 100 modules on ModularGrid with authorized VCV Rack clones. Soon we'll have more clones of Malekko, Grayscale, Befaco, and Mutable Instruments modules, as well as some brands I can't announce yet. If anyone sees any errors with the links, let me know here or by emailing [email protected].
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
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".
