[PD] accuracy of signal/message-objects

Roman Haefeli reduzierer at yahoo.de
Tue May 8 20:06:13 CEST 2007

On Tue, 2007-05-08 at 18:37 +0200, Steffen wrote:

> Marius also ends out with some explanation of the 'block' concept. I  
> think that what i don't really get.
> I understand that decreasing the block size will possible requirer  
> more computation/logical time then there is real time enough to  
> complete.

what do you mean by computational time? logical time and the time, the
cpu needs to compute something are not the same. 

>  And therefore that the information in a block is available  
> to the program to process. Which also means that after that block has  
> been processes the information is not longer available. Is that true?

i am afraid, i couldn't fully follow. i'll try to explain it in my own
words and hope that i don't tell too much rubbish, cause this is only
what i assume, how things are:

a block is a number of numbers, in pd these numbers are 32bit floats.
the usual blocksize is 64samples(=floats). audio signals are passed
blockwise between tilde-objects, that means a tilde-object receives 64
floats on its inlet, then processes  all 64 samples and then sends them
to its outlet. this happens each tick for the whole dsp tree. each tick,
a whole block is processed by the first object, then passed to the next
object, processed by this object, passed to the next and so on.
i assume, the cpu overhead, when decreasing the blocksize, comes from
the communication between the tilde objects. if the packagesize is
smaller, more packages need to be passed to process the same amount of
data in the same time, so more exchanges between tilde objects are
every tick, the 'message tree' is processed as well. so, in logical
time, messages always 'happen' at block boundaries. for example, when a
number is sent to the left inlet of an [osc~], the [osc~] changes its
frequency exactly on the blocksize boundaries. so, in logical time,
messages take effect only every 1.45ms (when running pd at 44100Hz). in
real time, you can't tell when exactly something is processed, it can
vary between immediately and the maximum of your soundcard buffer
setting. the sound card reads the samples from the buffer at a fixed
rate (the samplingrate), whereas pd does fill it at a speed, that
depends on the cpuload. although pd does compute things at nondefined
times, the output (of your soundcard) seems well timed, because pd puts
the samples in the right order into the buffer.   
> What is a block, what's in it, what properties does it have. Is a  
> block a sample or is a block made out of a number (being the block  
> size) of samples? And also Jamie's question: what does the 'v' stand  
> for?

i think, in [vd~], it stands for 'variable' (delay). i don't know, what
it means in [vline~] and [vsnapshot~], vector maybe, because the
messages, they receive can have an effect within the vector
(read:block), not only on block boundaries. these two objects are
special, because when they receive a message, that was initally
triggered by a [del] or a [metro], it has an effect within the block,
because the messages generated by [del][metro] are tagged with some
timestamp (is that correct?), so that [vsnapshot~]/[vline~] know, for
which exact time they are meant to be executed.

if i understood IOhannes correctly, he said, that other 'translations'
from pd to the 'real' world beside sending data to an audiocard cannot
be timed accurately, since they lack a fixed rate, like an audiocard has
it. for example, if you are talking to an arduino board, it will process
the data as soon as it gets it. so if the cpu load is currently a bit
higher, it will get the data probably a bit later, than when cpu load is
small (is that right, IOhannes?).
let's say i am running pd with a buffer of 100ms and the patch switches
often between high and low cpu-load (for example it does load some
audiofiles into arrays from time to time). would that mean, the maximum
jitter of the arduino outputs is 100ms, although i don't have any
dropouts in the audio? is that correct?


Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list