Can Rack v2 do block processing?

My understanding based on v0.6 was that the engine did not allow for processing a block of samples. Has that changed & if so, is there any kind of guide or example?

I imagine that there may a list of changes from v1 to v2 somewhere but my search powers seem to be failing me.

Hi @maw!

So modules can always do whatever they want (fill a block, then process when full while filling the net block) and a fair number of them, especially spectral processing ones, already do this. Obviously that adds additional latency to those modules. If that’s what you’re after, here’s a good starting point.

I think what you’re asking, though, is whether the engine itself supports block processing. I’m pretty confident that it does not and will not as of V2; even though it’s feeding the audio device in blocks, those are built sample-by-sample as the engine steps through the modules, then cables.

There’s some (veeeeery early) indication that this may change as of Rack V3, which has (again tentatively) been described as the performance update: see the dev blog here. I don’t think this would change any outputs, though, it would just potentially speed up processing on subgraphs without cycles (to somewhat simplify the issue…)

PS. The V2 changelog is here, by the way.


This is exactly right. Also, if I might add, it would be a pretty rotten modular synth if every cable had a block of delay in it. For obvious reasons.


This is a really important point. It’s a little like why you’d think twice about a big hardware modular filled with digital modules imposing little A/D and D/A costs everywhere. Writing this out, I’ve just realized that I loosely think about block-processing modules in Rack the way I think about DSP in Eurorack; they’re both great in the right spot, and they can do unique things (like FFTs!), but you want to be on top of where they are and you don’t necessarily want all that many of them.

I don’t know what Andrew has in mind with processBuffer() (mentioned in the V3 post) but my guess is that it’s intended to provide a module with a more efficient way to compute the same output if and when the hypothetically block-permitting V3 engine determines that block processing is graph-theoretically safe (meaning that block and sample processing will be equivalent–and heuristics for that are going to be the crux of this effort). Anyway, if that’s right, I imagine the default implementation would be to loop process() over everything in the block while managing args appropriately. Someday we shall see! But let’s enjoy V2 first :wink:


Thank you @gc3. Yes, this is actually the reason I asked. I was wondering what Andrew knew that I did not (probably in addition to many other things).

1 Like