Peter Plessas wrote:
Thanks for the discussion Roman,
see below
Roman Haefeli wrote:
while not being 100% sure, what frank meant with the other timing domain, i guess, he meant all the messages, that are not initiated by [metro]/[delay]/[pipe] and co. this would be messages from:
- the guis and clicks on message boxes
- networking objects [netreceive]/[tcpreceive] etc.
- [hid] / [comport] / [arduino] / [wiimote]
- [cltin] / [notein] / [midiin] etc.
- probably more
all those messages lack the extra timing information and thus are executed only at block boundaries.
That's the adc~/dac~ block boundaries, so...
I managed to find something that contradicts here: A Gui-bang to a [t b b] to a [timer] in a subpatch with a [block~ 8192]
...that's why.
object. Clicking the bang very fast with my mouse gives smaller than blocksize message intervals: print: 127.71 print: 116.1 print: 116.1 print: 127.71 print: 116.1 print: 127.71 print: 104.49 print: 92.8798 print: 104.49 print: 81.2698 print: 104.49 print: 116.1
note the quantisation!
127.7 ms = 88 blocks exactly 116.1 ms = 80 blocks exactly 104.5 ms = 72 blocks exactly 92.88 ms = 64 blocks exactly
at 44100Hz with 64 samples per block
so i'm guessing your audio driver has a block size of 512 samples (8 * 64), which Pd fills with its 64 sample blocks quicker than you can click twice => massive jitter of "logical time" vs "real time".
usw.
Hmmm, still searching. Thanks for all the good pointers!
regards, PP
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list