[PD] logical timing question

[Frank Barknecht]

Hallo,
Peter Plessas hat gesagt: // Peter Plessas wrote:

> That's what made me curious. Since the duration of a DSP-block does not 
> belong to the realm of clock-delayed messages 

Actually it does belong to the same realm AFAIK: Pd's clock is computed
using the audio card as a reference. "Subsample accuracy" just means,
that events can be scheduled between samples as well. 

But the time, when they should be scheduled, is still calculated from
the audio card. In the end [metro] will have the same jitter as the
audio card. 

Maybe an example makes this clearer: Lets assume you have a digital
watch that only shows hours and minutes, but no seconds. So it has a
sample rate of 1/60 Hz. 

Now you want to boil an egg for breakfast. You like your eggs if they
have been boiled for three and a half minutes. So you drop your egg into
the water when the watch is changing minutes. After three minutes you
start interpolating: You have to take the egg out of the water halfway
in between the ticks that come every minute. (If your watch has a lot of
jitter, you egg will be wrong, too.)

That's the same "sub-sample accuracy" Pd uses to schedule events that
should happpen in the middle of a block or between two samples.

For the nasty details check out Miller's book
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node43.html
where he explains the various possible techniques to use for
interpolating between two ticks.

Also see http://crca.ucsd.edu/~msp/techniques/latest/book-html/node52.html
for how it's implemented in Pd and everything else in that chapter, too.

> (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.
 
I don't understand what this has to do with [bang~]?

> Does anyone know about the real-life resolution of [realtime]?

I think this depends on how accurate your operation systems realtime
clock is.  On Linux, you can maybe check:
/proc/sys/dev/hpet/max-user-freq rsp. /proc/sys/dev/rtc/max-user-freq
for the max allowed polling frequency or so. But I'm no expert on this.

Ciao
-- 
Frank