Hello! Does anyone know if it would be possible to have a block size higher than 4096 in Rack, either integrated into VCV Audio 2 / 8 / 16 or through a custom audio interface module?
I’ve made a ton of patches over the past year+ that I can’t work on because they’ve become too complex for my CPU to handle, resulting in heavy audio stuttering. I tried the suggestions from Omri Cohen’s video which were helpful, but with each patch I eventually hit the same wall. Turning up the block size has made a huge difference for me but even at 4096 my computer is unable to handle most of these patches.
Can we go higher than 4096? I currently don’t use VCV Rack for live performances; instead I’ve been using it to create predetermined songs that play on their own after a single push trigger signal-- this is to say, I don’t care much about latency (even 10+ seconds is fine). I just want to avoid the skipping/stuttering which makes it impossible to hear what I’m working on. If someone were to develop a specialized interface module for absurdly high block sizes, or if VCV included them in the Audio modules, I (and probably many others) would be eternally grateful. : )
Unfortunately, after a certain point, increasing block size won’t help you. Larger blocks provide a buffer against changing loads, but they can’t offset a load that’s too high on average (unless the block length is, say, half the length of your song…)
Do you have Rack Pro? My suggestion would be to apply a mix of @karlderletzte’s advice and @Squinky’s advice during composing/patching, then (if it makes an audible difference) jack the sample rate back up, turn on as much oversampling as you like, swap back in any CPU-expensive modules that you couldn’t happily substitute, and do offline rendering. You should end up with a stutter-free recording on disk. I think VCV Recorder may also be immune to audible stutters but haven’t tested it.
If you don’t have Pro yet, and want to give this workflow a try, you could always rent it for a month through VCV+ and see if that solves your problem.
Bumping it down to 44.1k helps a little bit but not much, still a lot of stuttering. Any sample rate lower than that kind of defeats the purpose for me, as this issue is always present when I’m trying to adjust my mix and 24k is a little too unclear for that.
I check the CPU meters pretty often and tend to avoid some of the more demanding modules whenever possible.
I do have Rack Pro. Just to clarify… when you suggest that I do offline rendering, are you saying I should run the patch and record it with a module (such as VCV Record, which is indeed immune to stutters), reference the recording outside the application and make adjustments from there? If so, I tried that with my last patch and I found it to be pretty time consuming especially for tiny adjustments, but it looks like that might be the best option available right now. I’ve also been swapping out modules here and there, and I’ve even removed a bunch of parts from my next project and stored them in a separate patch, intending to paste them back in later (but this makes the mixing process difficult as I can’t hear all the instruments at once).
Ah ok, I see what you’re saying… although I would be very curious to hear how a block size 8192 or 16384 would affect my projects
Glad VCV Record does work as expected! Yes, that’s one way to do it. It might be easier to use built-in DAW functionality, though (“bounce to track” or the equivalent) with your patch loaded in Rack Pro VST. The docs give a dictionary of the feature names that are sometimes used in different DAWs. They describe a use case where the processing power needed is below the real-time power available; your case is the reverse, but the same workflow applies (it’ll just take longer-than-realtime to render).
If your patches have multiple separable instruments, you’re in luck: put each one on a separate track and bounce them separately, then mix. [EDIT: if it’s easier, you could also have one main patch, but manually disable sets of modules and bounce to separate tracks]. If it’s a big integrated generative patch with lots of cross-connections between branches, it’s obviously harder.
Happy to help you think through the workflow in more detail if you give a few more specifics about what you’re doing (i.e. are you mainly adjusting external channel settings or VST effects, or are you tweaking patch internals? Do you have expensive processes, like reverb, that you could turn off while tweaking and turn back on to bounce/render?)
I think that if you’re using Rack Pro in a DAW it inherits the block size from the DAW. Reaper, at least for some drivers, allows pretty large block sizes. The fundamental issue remains, though: the CPU still has to fill each block by the time the previous block finishes.
Each project/song is contained within its own patch, and I don’t add any effects/parts or adjust individual instrument levels outside of Rack (after recording with the VCV Record module, I do add a mastering chain to the track in my DAW before I post online, but I’m hoping to do the mastering within my patches in the future). When I first began, I used to run each individual track through Audio 16 modules into Soundflower/BlackHole into my DAW, but these days I run a single mixed down stereo signal into the Audio 2 module, which I either send directly to my computer speakers or headphones, or into a CAD audio interface connected to studio monitors and headphones. No DAW in between, just the Rack application.
This is a picture of my next patch, minus six instruments which would normally be in the empty spaces:
The song is turned on/off by the VCV Push module on the left side, four rows down. It triggers clocks and sequencers which control when the different instruments come in and out. I try to make my patches as un- ‘generative’ as possible, in the sense that I try my best to eliminate randomness and create as closely identical of a song as possible every time the button is pushed (this is why the module has so many cables attached- it resets almost every sequencer, oscillator, etc.)
Some instruments are heavily intertwined, but others I was able to disconnect from the patch and temporarily place into a different one. After moving out these six instruments and bypassing another, I’ve gotten the patch to run just well enough to finish working on the last instrument. But as I said this issue becomes most apparent in the mixing process, when I’m trying to hear all the different parts and how they interact with each other (at this stage I try not to bypass too many modules, even though it does help bring the percentage down).
As for bouncing in my DAW, that could be pretty useful for some of my other projects, but as you mentioned in these cases where I’m maxing out my CPU, it takes longer to render so it doesn’t make a huge difference from the Record module.
My DAW’s maximum block size is 1024 samples, so I might end up getting the Reaper trial and testing it out. I’ve had my eye on it for a while anyways, and if it allows me to better hear what I’m working on that’s a good enough reason for me.
A little update in case anyone’s interested: I downloaded Reaper and tried running VCV Rack as a VST. @gc3 's theory that the VST inherits the DAW’s block size is correct (I confirmed this in Logic too). I was also able to set much higher block sizes in Reaper, but unfortunately the VCV VST seems to have a strict upper limit of 4096 (the screenshot below was taken inside Reaper with a block size of 50000 samples, I also got the same results from 8192 and 16384):
I appreciate the pointers and I’ll definitely be exploring Reaper now. On another note, does anyone know if audio interface modules can be developed for Rack by users, or can those only be made by the VCV Rack team?
anyone can make an interface. don’t know if you can make one that uses a ginormous block size, but maybe? That said… why? VCV would become close to an offline renderer at that point… and it’s really unlikely you are using any modules that are that spikey. It would be a really bad module, but I guess anything’s possible.
@zitwoormce, the patch looks really interesting! Reaper is definitely worth exploring.
If you’re committed to trying larger block sizes you might look at the VCV Rack (non-Pro) source code and see where it’s getting the block size lists (I think it’s in audio.cpp) and see if you can add larger ones. But to echo @Squinky, this is almost certainly (as in, 99% certainty) not going to solve your problem for the reasons we’ve been talking about. Expect a few extra seconds of clean playback before it starts stuttering again. So my friendly recommendation is to go on this quest if you want to learn about audio interfaces, but don’t be disappointed if it doesn’t end up helping you make music…
You haven’t written a word about your CPU, but maybe it is worth to see if you can upgrade it, sometimes this is just the bottleneck,
and how many threads do you use for your patches, many threads are not the best idea for CPU usage. As the overhead gets bigger.
Just some thoughts, that maybe could help.
