Ok, my intuition was telling me that it needs to wait for "subpatch's blocksize" samples until it has enough samples to process its first block. But trying to make sense, it seems that for the first processing round it waits and fills with zeros until it can receive the block of 64 samples from the parent so it completes its block size, so we actually have the first bigger block of samples containing the 64 sample block from the parent! If you measure the difference, the latency is actually a bit shorter. Yeah, that makes sense in the end, phew...

The confusion comes from expecting that the larger reblocked subpatch needed to start and get its first samples from the incoming signal sent by the parent. Then you'd have to wait until a whole block is filled until it gets output next. Then the delay would be the block size, right?

Now onto the other part, which I can't figure out yet. Cause in my attached example, what I just mentioned in the last paragraph actually happens. You can have the blocks synced up and you can see in the output of print~ that the incoming block from the parent counts from 1 to 64, here's the console print.

The reblocked subpatch then counts from 1 to 128!

But the output is actually still delayed by (blocksize - 64). In the output I need a [delay 1 64 samp] object to get the same incoming block.

And I can't actually get my head around that, just seems weird and I can't make sense.

Cheers