[PD] accuracy of signal/message-objects

Frank Barknecht fbar at footils.org
Wed May 9 11:25:39 CEST 2007

marius schebella hat gesagt: // marius schebella wrote:

> does this all make sense?
> smaller blocksizes give you the possibility to handle messages in even 
> shorter time intervals, bigger blocksizes may help to declick for 
> example when you write to arrays. [for some objects blocksize is even 
> more important (fft~, tabsend~).]

I think, it may be easier to explain this from a practical point of
view. I'll give it a shot: 

* First axiom: Pd's messages are deterministic, also in time. 

What does this mean? All messages *inside* of Pd are handled with
(almost) complete accuracy. If you have a bang going through a [del
0.3] and going through [del 0.299] then you can be sure that Pd
triggers the 0.299-bang 0.001 msec before the 0.3-bang, regardless of
what your blocksize or so is. It would be terrible and lead to lots of
nasty errors if you couldn't rely on Pd to schedule events in that

* Second axiom: The GUI is updated or polled less often. 

It would be a complete waste of ressources to update the GUI or poll
GUI elements for changes every sample or every 1/44100 seconds. So
currently events coming from the GUI are only read once every 64
samples. This interval also is independent from the blocksize! You can
check this with attached patch by setting the blocksize to some really
big value like 23 seconds and bang the [random 8]: You don't have to
wait 23 seconds to get the result. Also with the [timer] object in
that patch you can see the quantization of GUI messages to
64 samples. 

* Third axiom: Converting between messages and signals is tricky.

As you've explained so well, DSP signals in Pd are calculated in
blocks of several samples in one go. Normally 64 samples are one such
block, but even with a blocksize of only 1 sample it would be tricky
to convert messages to signals correctly, because even one sample
takes a certain time (1/SR seconds) to compute. 

Generally DSP objects calculate a complete block and cannot react to
messages in between that time. The messages themselves are scheduled
correctly (Axiom 1) it's just that most DSP objects don't listen for
messages during their computation time. 

Some DSP objects however actually can react quicker than a block:
[vline~] and [vsnapshot~] are the prime examples. They use a little
trick to do so: While they still calculate a full block in advance
like everyone~ else, they "know" beforehand when messages are
scheduled to reach them possibly in the middle of such a block and
they calculate their sample block with these "future" messages in

This is possible for messages, that are scheduled to be send at some
future point in time. For example a [metro] generates this kind of
message: When a [metro 500] bangs, it also instructs Pd to bang again
after 500ms. [vline~] then can ask Pd: "Are there any messages scheduled
for me during the next block?" and because Pd knows about that
scheduled [metro]-bang, it can tell [vline~]: "Yes, there is one bang
waiting for you 0.526 msec into the next block. Please take this into

The normal [line~] object doesn't ask Pd about such scheduled messages
and as such is faster to compute. If you just need to declick some
value from a slider, then you can just use [line~] instead of [vline~]
because slider events don't happen faster than 64 samples anyway. But
if you build a drum machine that is driven by [metro] , you should
really use [vline~] to get a drumset, that is not only good enough for
acousmatic music, but also good enough for Jazz, as Eric Lyon once put it.

 Frank Barknecht                 _ ______footils.org_ __goto10.org__

More information about the Pd-list mailing list