Midi Merge Technique? (Jitter)

[Byron G. Jacquot]

>There is one thing that all of us have overlooked as far as jitter is
>concerned. Including myself until now. And that is, the receiving end, if
>it's any good, has to have a PLL or fly-wheel circuit. Whether that be
>software or hardware. And what this does is overcome Jitter.
>
>Often called a flywheel circuit because of it's similarities to a big heavy
>flywheel with a lot of momentum. It takes a lot to change the speed over a
>long time. Which means the speed is pretty damn constant at the receiving
>end. regardless of how much jitter there is. (to a point of course)
>
>And of course. The reaction time of the PLL is set up so that a fast rate
>of change (accellarando/decellarando) can occur but jitter and even missing
>pulses can be circumvented.
>
>So I guess, as long as the jitter isn't so bad that it represents an actual
>tempo change, there isn't going to be much of a problem.

I think this thread just veered away from where Batz was taking it.  From
what I read into the above, he's not so worried about the jitter of the data
bits on the transmission lines...besides, there are all sorts of handy,
oversampled UARTs out there than do that in hardware.

I think he's talking about the actual use of incoming $f8 MIDI clock ticks
to generate a more stable tempo source for making music.

Imagine a MIDI transmitting device that doesnt allow for the interruption of
sysex by system real time messages (Mainly MIDI clock info).  It starts
sending a large chunk of sysex, and partway through, an the timer that
generates clocks turns over...as soon as the chunk if done, it sends the
MIDI clock byte.

On the playback end, the sequence playback mechanism is simply waiting for
that byte to arrive before advancing the sequence by 1/96th note.  If that
byte arrives on time, the percieved sequence playback is "in time."  If that
byte is early or late, then the whole sequence will be early or late.

I think what's being proposed is to use a software flywheel mechanism to
help aviod hiccups in the sequence when clock ticks are early or late.

A simple flywheel might keep track of the times (in ms or system timer
clocks, or whatever) between the last N MIDI clock messages.  It could then
average those values, and expect the next MIDI clock to arrive at that
time...if the system decides the MIDI clock is unacceptably late, it can act
as if that clock pulse had been recieved already, play the next step of the
sequence, and wait for that clock to actually arrive. Vice versa if the next
clock is unacceptably early.

By subdividing those average interim stretches, it might be possible to have
greater than 24 PPQ resolution, too.

For a similar type of problem, we could always look into how some of those
SMPTE regenerator boxes work.  The interval between messages is relatively
fixed in a TV/film system, and late/missing messages are a bigger pain to
have to work around.  I'm sure that technology could be adapted.

This handles situations where clocks may be early/late or missing, but
doesn't help too much when it's just plain _wrong_.  On my TR909, if I hit
stop then continue, then stop, then continue, etc. will start inserting
extra clock ticks between the stop/continue messages.  Anything synced to
it's clock will then see extra ticks, and start to drift behind the 909.  As
far as I've tested, the ticks are in time, just on the wrong side of the
continue message.  There may be a race condition at work here...

Byron