[PD] logical timing question

[Roman Haefeli]

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