You have to be careful reblocking with [tabsend~] and [tabreceive~] though, because of what happens with blocking and block delay. Hopefully this isn't too obvious to explain.
You know the regular situation: suppose you write into the [inlet~] of a subpatch that is blocked at 128 from a parent blocked at 64, and then back out an [outlet~] into the parent patch. When you start dsp, for the first parent block the first 64 samples go in, but nothing comes out because the subpatch needs to collect 128 samples before it sends anything out. On the second parent block, 64 more samples go in, the subpatch can do its calculations on its 128-sample vector(s), and start output immediately, beginning with the first block of input from the parent patch. So everything is delayed by one block in this case, or in general by N_s - N_p where N_s is the subpatch's block size and N_p is the parent's.
Now, suppose instead you have an array of size 128 called "depot." From the block-64 parent you [tabsend~] a signal to depot, and you make sure your signal is calculated prior to anything in the subpatch using the [inlet~] trick. [tabsend~ depot] will write the first 64 samples of depot every block, leaving the last 64 untouched. Then inside the block-128 subpatch you [tabreceive~ depot] and send it out to the parent through an [outlet~]. What will happen? When you start dsp, during the parent's first block [tabsend~ depot] writes the first block of samples to depot. Nothing happens in the subpatch because 128 samples haven't passed yet. Then on the parent's second block, [tabsend~ depot] writes the second block of samples to the first 64 samples of depot. 128 samples have passed, so the subpatch can do its thing. [tabreceive~ depot] receives the whole array, starting with the 64 samples just written in by the second parent block, so on output, those 64 samples come out with no block delay. However, since the first parent block's samples were overwritten in depot by the second block's samples, every other block from the parent will be lost in the subpatch. However, if you set the subpatch to overlap by 2 (or generally N_s/N_p), the [tabsend~]/[tabreceive~] pair actually allows you to reblock with no block delay and no lost samples, but with the CPU penalty and the general hassle of dealing with overlapping. It would allow you to do things like partitioned convolution without any delay, since the convolution of two 64-sample windows fills a 128-sample window.
So, knowing this, what do you think would happen if you put the [tabsend~] in the subpatch and the [tabreceive~] in the parent and don't overlap in the subpatch? What if you do overlap in the subpatch?
NB - overlapping does not affect the block delay of normal [input~]/[output~].
I now realize I should have just built a patch to illustrate all this. Next time. :)
Matt