Mode Test de l'horloge MIDI

In einer eMail vom 03.10.01 20:40:57 (MEZ) - Mitteleurop. Sommerzeit schreibt 
deepsound@balcab.ch:

> I am using an amt8 and cubase since 1,5 years, there is no problem, tight
> midi-timing, in my eyes better than the midex 8...........i am working with
> winME.

It's time to do some promotion for the Midex 8 !


We have actually developed the Midex 8 and LTB for Steinberg.

The root idea for LTB (LinearTimeBase) was initiated by a bug in the Virus 
several years ago. Some of you might remember it:
When the Virus Arpeggiator was synced to Midi Clock, the Arpeggiator slightly 
drifted away from the original beat; it just went a bit slower than it should.
It was a miracle to me, the only explanation was that either the computer 
does not send a small percentage of the Clock messages, or the Virus looses 
them.
But how could a system loose just a small portion of messages?
In the Virus this can only happen, when two clocks are sent immediately after 
another, in that case it lost the second clock.
But how can two clocks be sent right after another - they should have a 
distance of about 20 ms at 120 bpm? A midi timing jitter of up to 20 ms from 
the sequencer!!

I tested this, and it was the jitter!

I needed to redesign the whole clock engine in the Virus, especially to have 
a smooth tempo measurement for the Delay, to sync it to the clock without 
producing clicks by that horrible jitter.
That new clock engine is LinearTimeBase, and it makes the arpeggiator and the 
delay unsensitive of clock jitter. It's in the Virus since Virus a.

Later I realised that we could design a Midi Interface, using the same 
technic.

I offered this concept to Steinberg, which is now the Midex 8.

The Midex 8 has a better timing than the AMT or Unitor working with Cubase. 
When you drive a Midi-Interface without jitter-rejection by USB, this adds 
another one Millisecond jitter to the data stream, due to the USB framing.
The Midex 8 archieves a timing accuracy of better than 300 µs, that is the 
lenght of one Midi Byte - independent of the condition of the computer or 
operating system. 
It bridges every timing information, and makes the computer working as a 
non-realtime machine.

Try this: Everybody can measure the sequencer and interface timing using the 
Virus.

- Switch the Virus LED Mode to " --- ". It's the "secret" timing jitter 
measure mode.
- Enable MidiClock Send in your sequencer.
- Set song tempo to 140.
- Start the sequencer.

You will see one of the LFO-LEDs light up, showing that the Virus adapts to 
the song tempo. After a while the LED's should stop
blinking. Every blink of the upper LED is a Midi Clock that came in too 
early; a blink of the lower LED is a Clock that came too late.

That measurement is not very accurate, it only shows jitter greater than 2-3 
ms. Thus, they should not blink when driven by a good system.


On software sequencers the timing is mostly independent of the density of the 
arrangement, but this must not be the case on hardware sequencers.
Test your favorite dense midi arrangement on a hardware sequencer. Maybe the 
result is a surprise.


Even on high midi traffic the midi clock should be stable, since it has the 
highest priority when transmitted by midi.

Reply to me, if you have any questions; this is an interesting topic.

Tell us your results!


Christoph Kemper
access music

_______________________________________________
access-list mailing list
access-list@ampfea.org
http://www.ampfea.org/mailman/listinfo/access-list   <--- SUBSCRIBE/UNSUBSCRIBE DETAILS HERE