On 03/12/2015 09:16 PM, Cyrille Henry wrote:
- from the outside, clock accuracy is related to block size and sample
rate.
i think this is a but misleading, as it completely ignores the output objects.
e.g. when dealing with audio-processing, audio samples are calculated in bursts of small blocks (usually 64samples). even if those bursts would be processed at a fixed clock (e.g. every 1.5ms), i'm sure that we all agree that this does not match what we are hearing: we do hear a (DA-converted) steady stream of samples at a fixed rate of (say) 44.1kHz rather a burst each 1.5ms of 64 very short samples. in practice this should be even worse, as the 1.5ms between the blocks may be slightly shorter or longer, depending on what else is going on on your system. you can tweak how long these blocks can get with the "audiobuffer" parameter in Pd's audio settings. If you put there "100ms" you *might* end up with all the audio processing being done only ever 0.1 seconds.
but we don't hear our sound cards making stuttering at 10Hz. (most of the times, at least). we also don't hear any sample jitter (unless we have some serious shit of soundcard).
this is mainly because Pd doesnt play back samples into our ears, but it sends them to a soundcard, which has a buffer and which uses some quartz or other rather precise clock that is synchronized to the "real world" to play back those samples.
so the timing resolution of the audio processing is handled mainly by your output device and by the objects that communicate with this device.
the same *can* be (made) true for any event that happens in Pd's logical time and that needs to be converted to some "real world event".
unfortunately it often isn't, because...
- it doesn't really matter (e.g. who cares about precise timing when
printing "bang" to the Pd-console)
- a device doesn't provide a means to specify exactly when it will react
onto an event
- the API that handles communication with a device, doesn't provide a
means to specify exactly when it will react onto an event
- the object's author was lazy and didn't care about telling the device
when the events should appear (but rather tells them to make them happen "now" - with "now" being the jittery burst when the CPU sees the events)
- other reasons
gdsrt IOhannes