On Sun, 2009-01-11 at 14:05 +0100, Peter Plessas wrote: > Hi again, > > Frank(ly), there is still something unclear to me. Please see below. > > Frank Barknecht wrote: > > In general, Pd has like to times: One is the time realm of clock-delayed > > messages, i.e. everything that originates in a clock objects like metro, > > delay, pipe, qlist, etc. Clock delayed messages have sub-sample > > accuracy. This is achieved by "tagging" each normal message with a time > > tag, similar to the old time tagged triggers in t3_lib. The tags for > > clocks are invisible, though. > > I understand you mean "Pd has two times", the first one being the > sub-samply accuracy of clock-delayed objects like [delay]. > (I exclude metro from this group since it has the hard-coded limit of > integer msec values).
this is not true. [metro] also works with non-integer time intervals, though it has a hardcoded lower limit of 1ms (i guess, that is some kind of stack overflow protection). > What would be the other "timing" then? 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. for the same reasons explained in the previous mail about [realtime], all those object classes seem to suffer from a big (bigger than 1 block) and audio driver/settings dependent jitter as well. you don't exactly know, when those messages arrive in pd. roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list