Hallo, martin.peach@sympatico.ca hat gesagt: // martin.peach@sympatico.ca wrote:

I think the bangs are independent but they don't get processed until any pending samples have been dealt with. That was the impression I got when testing [comport] by setting the DTR pin using [metro]: there is always a jitter of a few milliseconds. Maybe it's the OS that causes the jitter, but it was about the same on WinXP and linux.

I think, it's comport's fault: [metro] generates clock-delayed messages. These are like messages tagged with a time-stamp referring to Pd's internal clock. However an object needs to actually use the time-stamps and "look at the clock" to see what time it is. Objects like [vline~] or [delay] do this, but comport doesn't.

Also looking at the pd code, as far as I could follow it, the control signals seem to be processed in between signal blocks, so that, for instance, a metro bang that happens in the middle of a signal block will not be processed until after that block, so yes, the metro can tick whenever it wants but the bang won't occur until after the current sample block has been processed. If it happens to tick in between sample blocks then the bang will happen at the correct time.

I think, basically that is correct, that's why evaluating the time-stamps of clock-delayed message is important, if you want to avoid jitter.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__