[PD] logical timing question

Peter Plessas plessas at mur.at
Sun Jan 11 12:26:29 CET 2009

Hi all,

Frank Barknecht wrote:
> Hallo,
> Peter Plessas hat gesagt: // Peter Plessas wrote:
>> i have a question regarding timing in Pd:
>> I understand that messages to tilde objects just get passed to the DSP 
>> tree within DSP blocks.
>> How about the reverse?
>> Found out that snapshot~ is returning the last sample of the last block 
>> during which it got banged. This is fine, since it is the sample value 
>> most closely to the output of the result.
>> Now when i use the following setup:
>> [bang~]
>>   |
>>   |
>> [t b b]
>>   |   |
>>   |   |
>> [timer]
>> i get a minimum logical time of 1.45 msec (aquivalent to 64samples at 
>> 44.1 kHz) even when i use a blocksize of [block~ 32]. 
> I think, bang~ should bang after each block, so
> with [block~ 32] it should bang every 32 samples. But it seems to have a
> lower limit of 64 samples. Don't know why.

thanks for the reply, Frank.

That's what made me curious. Since the duration of a DSP-block does not 
belong to the realm of clock-delayed messages (pd can't know of the 
exact duration of the DSP block, assume f.e. an external audio clock 
with jitter) those values may have to be "sampled" by the messaging 
system. This sampling would then appear at a minimum rate of 64 samps.
So bang~ only makes sense for blocksizes greater than 32 samples, right?
Phew, does that make sense? Still trying to completely understand that.

> In general, Pd has like to times: One is the time realm of clock-delayed
> messages, i.e. everything that originates in a clock objects like metro,
> delay, pipe, qlist, etc. Clock delayed messages have sub-sample
> accuracy. This is achieved by "tagging" each normal message with a time
> tag, similar to the old time tagged triggers in t3_lib. The tags for
> clocks are invisible, though. 

Timing is a very interesting topic in pd (and with computers in 
general). When i try to measure the [realtime] of a [metro 4] object, i get:
print: 11.351
print: 0.122
print: 0.11
print: 11.402
print: 0.088
print: 0.119
print: 11.374

I think you get the same values. Can it be true that there is a 
deviation of 7ms now and then? More interesting: Why is it not only 
now-and-then, but every fourth sample? So there must be some phase shift 
which accumulates in the operation of [realtime].
On averaging those values, one gets a value close to 4ms though.
Does anyone know about the real-life resolution of [realtime]?


More information about the Pd-list mailing list