I tried to make a patch where I can select between different modules using Stoermelders STRIP for fast module switching that I can control via Midi CC, but I noticed that as the number of disabled modules grew, the performance decreased. By performance, I mean the number of XRUN’s thrown by Jack, and the amount of ‘clipping’ noises.
So I was wondering if disabling modules removes their cpu overhead? I thought that they did at first but I’m not sure now.
Yes, a disabled module does not process any DSP and does not consume any CPU cycles for processing. It still consumes GPU as the module must be rendered on your screen.
That been said I’ve seen modules misbehaving when disabled and consuming even more CPU.
Is it possible for a module to tell another to disable/enable? I.e. assuming you have a large multi-instrument patch, could you select parts to be enabled/disabled from a controller generated trigger?
In that case I think my modules are misbehaving, because once I delete all the disabled modules the performance goes back to normal.
I also confirm that disabling a module makes it consume nearly zero DSP time. But I’ve never seen a module take more CPU when disabled. Open a bug report if you can find a reproducible example.
In Rack v2, the “disable” feature will be renamed to “bypass”, and Module::processBypass() will be called instead of process() so theoretically a module could do more work in the bypass method although this will be rare in practice.
You’re right, I should do that. I think it was one of the Nysthi modules which uses a worker thread for FFT or something…
Ah, that makes sense. Code like
loop:
if module is ready:
processFFT()
yield()
would enter a yield loop which might use more CPU than simply processing the FFTs. Better to use signals/mutexes.
Posting in this thread since it’s relevant.
I’m preparing for live performance with VCV Rack and am hoping to bypass segments of patches using Stoermelder STRIP to keep CPU under control while I mix beginnings into endings of songs. I have a playlist of 10 songs that I want to perform, each with 50-80 modules so have created a mega patch with each song feeding into its own mixer which feeds into a master mixer that feeds the output. Right now with everything bypassed my CPU is at 65% max, which means that when I enable even a single track it hits >100% and I get playback artefacts. I’m not sure what the reason is for such high usage with everything bypassed, I’m on a macbook air M3, would this all be GPU? Unless there’s a simple solution for this that I haven’t considered (I’ve reduced sample rate to 44 kHz and framerate to 10 Hz, no tooltips or performance meters, scopes and other eye candy removed) I will either have to split my set in 2 or delete played patches while importing new ones as selections. Any tips that I can try?
Diagnostically: bypassing does save the CPU required by the bypassed modules’ process call, but (in addition to the visual load, as you mention) the cable connections are still running, which is likely at least some of your 65%. (I haven’t separately benchmarked the components, but if cables account for 5% of the CPU load of a normal full-track patch, which seems reasonable, I’d expect that putting ten full sets of cables together in one monster patch would be a noticeable load.)
Whatever the cause, the only idea I have offhand is using VCV Pro (if you don’t have it, you can rent it for a month with VCV+ and see if it helps). Consider putting each patch in a separate Rack instance on a separate DAW track (so you’ll have ten separate tracks). Set up your DAW to fully disable plugins on muted tracks, and then automate accordingly. If you want a little glue for transitions, you can use send FX so that the send from track 1 hits (say) a reverb that’s still decaying while track 2 starts. You can automate the sends so you don’t have the reverb (or whatever) going over your whole song. As a bonus, this would be an easy way to have variety in transitions (always an issue in modular performance, hardware or not.)
No guarantee it’ll work (or fit your performance criteria even if it works technically) but it might be worth a shot…
Hmm, this is a bit mysterious. For me on M1 mini and M2 air, I typically don’t get any hiccups until over 200% CPU.
In Activity Monitor, look at the CPU and GPU usage, but also memory. Often memory swap is the cause, when I start hearing hiccups.
And you probably know that you want the number of threads in Rack set to 1.
Also try setting the buffer in Rack as high as you can while still being able to play.
a playlist of 10 songs that I want to perform, each with 50-80 modules
Wait, so how many modules are there on your ‘Mega Patch’? Surely not 500 - 800?
Thanks for the suggestion, it must be the cables. I didn’t know they still ran if the modules are bypassed. I tried the DAW approach early in my prep, but found that even two patches open at the same time gave artefacts due to the additional overhead of the DAW itself.
I just came across this Hotswapping between the Strips in VCV Rack Video when i was looking into the Strip module by Stoermelder. I haven’t tried it yet but it looks like a neat thing. Btw it’s 4 years old, it’s probably not necessary to install the development version from Github.
Thanks for the suggestion waldo. In activity monitor I’m idling at 120% CPU with all modules bypassed, so I must be hitting >200% when one patch starts running. GPU is around 12% so that’s obviously ruled out as a problem. And yes, there really are that may modules in the mega patch, that’s why I was hoping to enable/disable as needed. Perhaps I need to explore a fixed rack for future live performance.
Wow! The scale of all that is impressive. The VCV equivalent of a giant wall of subwoofers?
An alternative suggestion. Computers are cheap (in terms of processing power / €$¥) these days. If you have another machine, or can borrow one (or two??) then you could have different patches queued up and bounce back and forth from laptop to laptop. I guess this idea might or might not work depending on how much human input you need to drive your performance, especially at the start and end of songs.