I'm dissecting a patch using fourier analysis and have discovered the tabreceive function. according to the help file for this object, the object serves to "read a block of a signal from an array continuously." i don't really understand what this means. Specifically in this patch, there is an array in which one can draw a filter (the x axis is frequency and the y axis is amplitude). It is this array that is accessed with the tabreceive object. What i don't understand is how what information is being output and how is it organized ?

Basically, what it does is cycle through a block's worth of array elements aligned with each block. So if your block size is 128, then [tabreceive~] will spit out the first 128 elements of the array on each block, one element for each sample. It's kind of like having a [phasor~] with the frequency quantized to the block frequency (sample rate/block size) and phase quantized to block boundaries, and then having that [phasor~] read the array.

awesome. thank you. my next question would be what exactly is a block? i've found the object block~ and read through the helpfile. i sort of get it, but i'm not totally clear. what does this actually do and of what consequence is it?

actually, I think a great tutorial explaining block, it's principles and uses; properly, is sorely needed. I was at one of Obiwannabe's seminar's today. I desperately wanted to bring this up with him, but sadly there was no time

I agree, arif. A comprehensive and easy to understand tutorial would go a long way. From what I understand, blocks are essentially buffers meant to make audio computation more efficient. If every sample had to be calculated individually, that means computation must happen at the sample rate (for example, 44100 times per second). Blocks (also referred to as vectors in other programs) allow calculations to be performed on groups of samples. By default, Pd uses blocks of 64 samples, but this can be adjusted per patch/subpatch using [block~]. This can help streamline the code so that some variables that don't need to be updated at every sample can be initialized at the beginning of the block, and then loops can be run on the 64 samples using only the necessary code. It also gives the cpu a little bit of leeway; in case computation falls behind (as a result of other processes interfering, for example) it has some headroom to catch back up.

It does impose a delay of the block size, though. The computations that are going on in the "current" block won't be heard until the next block. While that block is playing, computation of the next block will begin, and so on. That is why in some cases, such as feedback delays, you have to reduce the block size so you aren't getting those samples too late.

I must admit, though, that I don't really get how overlapping blocks work. Does it essentially just make multiple instances of the subpatch and have their blocks offset by the amount of overlap? I imagine some of you out there who have made your own externals have a better understanding, so please chime in and correct me if I'm wrong!