I don't have a tempest, but what you're seeing in terms of slight random timing is actually to do with the way MIDI clock is handled and not (necessarily) the Tempest in particular.
MIDI is an asynchronous protocol - packets are sent whenever the host has data to send and the timing of those packets is literal - as in the nanosecond I woggle the wire to put the bit on it, the bit is there, and when the full packet has been sent, that's the timing of the message.
MIDI clock is sent very simply, a clock pulse packet is sent down the MIDI wire, and 1/24th of the BPM later, another, and another, etc. So if the BPM is 120, 2,880 packets will be sent per minute, all more-or-less evenly spaced in time. Most hosts display a non-smoothed calculated from the (local, perceived) time of the last two packets, divided by 24 and scaled to bpm, and update this value every X milliseconds from whatever the last two packets' timing was.
This works perfectly fine if there is no other MIDI data on the wire.
But as soon as you have even a single other piece of MIDI data to send (say a note event - which is always two packets, the on and the off, or a cc, or even the start/stop commands) those might be sent "on" the beat or on one of the common subdivisions of the beat (8th notes, 16ths, even triplets). All of these are at one of the exact moments one of the 24 clock pulses will also need to be sent. In some cases, depending on the real-world timing of these events, processor queueing, and other vagaries, the note/cc/other MIDI event will be sent first, in or across the time boundary where the clock pulse should be, and the clock pulse must be moved to immediately follow the MIDI event. This is only the case if the SENDING unit is also creating the additional traffic or if the traffic is being merged with a clock signal that is generated independently, AND the merger or the sending unit do not have the ability to look ahead and determine if the clock pulse should be prioritized. Most machines operate on a First-In-First-Out pattern so if the note data gets put into the sending buffer before the clock pulse, the note data will shove the clock pulse the few milliseconds it takes to send the other packet first.
As a result, it's entirely possible to see the clock fluctuating by small tenths of a beat if there is any other midi traffic (especially perfectly timed sequence data such as drum beats) on the same cable. Since the Analog RYTM cannot and does not sequence other gear, this is not possible, so its timing will always look 'cleaner' than a drum machine (such as the Tempest) which can sequence other gear and is thus a bit more chatty.
34 Replies
16922 Views