Can anyone tell me how audio data goes through a pd patch? here is my scenario and my sugestion about it. the main patcher has by default a block size of 64. on it i have a sub patch reblocked to 1024. the signal flow is: adc~ on main patcher goes into the reblocked subpatch (just goes unprocessed through it) and back to the main patcher with 64 block-size (i've attached a pd file). okay. what happens to the audio stream?

my sugestion is: the adc~ object throws every 64 samples (block-size/samplerate of 44100 = 2.9ms) a block of 64 numbers( i.e. bits) out of its outlet and into tihe inlet of the reblocked subpatch. within the 1024 reblocked subpatch pd waits until it gets 16 frames from the main patcher (64*16=1024) and throws this as on 1024 frame out of its outlet back to the main patcher. in the meantime the main patcher has send 16 empty frames to the dac~ until the 1024 frame comes from the subpatch. but how does the main patcher process the big 1024 frame?? does it only takes the first 64 bits of it?? how does this work?

http://www.pdpatchrepo.info/hurleur/Untitled-1.pd

I haven't looked at the source, but I imagine it just chops it up. You could think of it as a 1024-sample buffer reading back 64-sample slices at a time.

that would explain the problem when you do a rfft~ in a reblocked subpatch and the rifft~ in the mainpatcher.

and whats with the non audio control signals. does a reblocked subpatch has any effect on them? or does these "signals" have their own clock?

Messages are passed along as individual events and are processed as soon as they are triggered. They don't conform to any kind of master clock (unless, of course, you make one with [metro]). The only time the block size should matter is when they are used to trigger audio objects, as their effect won't appear until the next block.