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