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