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]?
cheers, Peter