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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list