Frank Barknecht wrote:
> Hallo,

> Objects like [delay] or [metro] produce these clock-delayed messages.
> They register their clocks with Pd's main scheduler using
> clock_new(...) and then order the scheduler to generate the
> clock-delayed messages like the metro-bangs using clock_delay(). The
> actual output of [delay], [metro] etc. then is initiated by the
> scheduler which calls the registered clock methods: delay_tick(),
> metro_tick(),...
> 
> However I must admit, I'm not sure how this relates to comport and if
> comport should also register its port-writing-method with a clock and
> let the scheduler "tick" the clock and initiate the writing and if
> that could get rid of the jitter you mentioned. 

no, this won't work.

[metro] is arbitrarily accurate within pd-land: here we deal with
"logical" time, where the execution of a message (and everything it
triggers directly) is happening in zero-time by definition.

in the world outside, there is no "logical" time, there is only the
"real" time, where the execution of messages takes some cpu-cycles and
thus real time.

messages are dealt with during dsp-cycles (in fact, dsp-cycles are dealt
with in between msg-cycles; this is why a message-overload can lead to
click, when one dsp-cycle has to be dropped).

in "real" time messages are executed in bursts, but for each message in
the burst the "logical" time will be correctly set.

this is all fine as long as you don't have to deal with the world outside:
the only place where this is handled somehow correctly is with audio: pd
writes the samples (who live in "logical" time land) into a buffer; the
soundcard reads this buffer in sync with the "real" time.
as long as the 2 time references are roughly in synch everything goes
well; when they get badly out of synch (drift>buffersize), you will get
audio-dropouts.

when dealing with other world outside interfaces (e.g. parallel/serial
port), there might be no such mechanism: whenever some data is sent to
the port (regardless of the "logical" time) it is visible "on the other
side in "real" time; this might appear in bursts and have a jitter.
the only way to overcome this is to create a buffer that synchs the two
time references.

a simple way to do this is to just overdrive the port a little bit, so
that your operating system's port buffer is always filled.

> 
> At least "normal" objects like [float] don't do any funky clock-stuff
> and still don't disturb the correct timing of clock-delayed messages.

because they do not interface with the world outside.



mf.asr
IOhannes

_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to