[PD] maximum "control rate" in Pd

[IOhannes m zmölnig]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150313/169b89d1/attachment.sig>