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