Midi Merge Technique? (Jitter)

[Fraser, Colin J]

> -----Original Message-----
> From: Byron G. Jacquot [mailto:thescum at surfree.com]
> Sent: 23 January 2000 20:34
> To: synth-diy at mailhost.bpa.nl
> Subject: Re: Midi Merge Technique? (Jitter)
> 
> 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.

>From the midi spec details posted, this would be incorrect operation - midi
realtime should always be sent as soon as required, and can interrupt any
other type of message.

> 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.

That sounds like an awful lot of work just to compensate for a poor quality
sync source.

A midi byte takes roughly 0.3ms to be transmitted.
As we have discovered that midi clock can be transmitted at any time (even
during sys-ex), if we write the transmitting software correctly, the longest
we need to wait before we can transmit a clock byte is the 0.3ms it takes to
finish sending the last message byte.
This gives us a maximum delay from the loading of the clock byte into the
transmitting UART, to setting the data ready flag at the receiving UART of
well under 1ms.
Theoretically, not a problem.

Of course, this will never happen in practice if you use a PC as your master
sync source.
I gave up using the PC for sequencing partly because of the poor timing.

At the moment I use a TR626 as the main clock source.
At any given clock interval, its sequencer always sends the midi clock byte
before it sends any of the note ons for the drums, so it is highly stable as
a source of sync.
(Midi-OX is highly recommended for analysing midi streams on your PC, BTW)

My main sequencer is my own design, and timing is absolutely critical, so
midi realtime is the first thing the interrupt routine looks for.
If it receives midi clock, it immediately re-transmits it (interrupting any
other message) before calling the sequence playback routine.

>From a quick look at the code, the delay here can't be any more than 2ms
between the clock arriving at the input of the sequencer, and the
re-transmitted clock arriving at the next device.

My point being that midi itself should be capable of accurate enough timing
with imperceptible jitter, as long as the software involved is written well,
and is truly *realtime* - ie a midi clock has arrived; process it now ! (no
waiting for Bill G to earn another dollar)

> 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...

I believe that bug is fixed in version 2 of the 909 firmware.
You can hold down a key to get the version displayed on startup (can't
remember what, I'll check if you're interested)


Colin f