[PD] logical timing question
plessas at mur.at
Sun Jan 11 12:26:29 CET 2009
Frank Barknecht wrote:
> 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:
>> [t b b]
>> | |
>> | |
>> 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:
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