Last night I investigated MIDI latency and jitter with various MIDI devices.
 
The setup is simple:

• A single perfectly quantized 1/16 MIDI note is send to a  MIDI OUT port
• A short MIDI cable connects MIDI OUT to MIDI IN of the same device (i.e. no external processing, filtering, etc. involved)
• The MIDI note is recorded on a separate track, its offset measured in reported MIDI ticks (960 tick resolution, project tempo: 240 BPM) and converted to msecs. Jitter is calculated as the difference between minimum and maximum offsets obtained in loop recordings (20+ loops)

Measurements where done on 2 DAWs with different specs, using Sonar Platinum 2016.07 under win10 (all updates in place).
 
 
First of all, Sonar is doing fine ... as can be seen from numbers obtained when using a virtual MIDI cable. There is a minor offset (1 msec) and small variance (1 msec jitter), which is expected as the signal is leaving Sonar into another application and comes back ...
 
loopMIDI (virtual MIDI cable) => offset: 4 - 8 ticks (1.04 - 2.08msec) => jitter: 4 ticks (1.04 msec)
 
Now results get interesting: the cheap MIDIMATE unit shows same performance as good Roland interfaces (i.e. expensive Roland VS-700 and widely used A-Pro MIDI Controller keyboard)
MIDIMATE            => offset:  7 - 12 ticks (1.82 - 3.13msec)   => jitter:  5 ticks (1.3 msec)
Roland VS-700       => offset:  5 - 11 ticks (1.30 - 2.86msec)   => jitter:  6 ticks (1.56 msec)
Roland A-Pro        => offset:  4 - 11 ticks (1.04 - 2.86msec)   => jitter:  7 ticks (1.82 msec)
 
Later Roland units seem to have more offset and slightly less stable performance ...
Roland INTEGRA-7    => offset:  8 - 14 ticks (2.08 - 3.65msec)   => jitter:  6 ticks (1.56 msec)
Roland Octa-Capture => offset: 10 - 18 ticks (2.60 - 4.69msec)   => jitter:  8 ticks (2.08 msec)
 
One of the most expensive MIDI only devices currently available, however, which is advertised having "giving you high-speed MIDI throughput, sub-millisecond timing accuracy" is quite disappointing because offset + jitter is 2-3 times higher than with other units and gets you into the timing critical range (~8ms with occasional peaks even higher)
MOTU Express XT     => offset: 16 - 32 ticks (4.17 - 8.33msec)   => jitter: 16 ticks (4.17 msec)
 
The MOTU unit comes with many options for locking it to external and internal clocking but neither option changes above measurements (so I wonder if this unit is functioning properly) ...
 
As regards Sonar: Is there any setting/option which would allow to move all recorded MIDI forward by the measured average offset (per interface)?
 
 
Edit: Behringer BCF added ...
Behringer BCF       => offset:  8 - 14 ticks (2.08 - 3.65msec)   => jitter:  6 ticks (1.56 msec)
 
Edit #2:
ESI M4U XT (win default driver) => offset: 8 - 12 ticks (2.08 - 3.13msec) => jitter: 4 ticks (1.04 msec)
ESI M4U XT (ESI driver)         => offset: 8 - 11 ticks (2.08 - 2.86msec) => jitter: 3 ticks (0.78 msec)

Interesting Rob. 6 to 8 ticks seems to be pretty standard, and good enough for most purposes at least.
 
At around 20 times the cost and half the performance of the ESI, I would love to hear what MOTU had to say about your findings.
 
The only adjustment I am aware of that MAY affect this on a per interface/driver basis is the ignoremidiintimestamp setting in ttseq.ini. Others may know more! 
 
https://www.cakewalk.com/Documentation?product=SONAR%20X2&language=3&help=INI_Files.5.html
 

thanks so much for this info!  I love recording but my computer skills lack severely.  I use a roland octa-capture and this is the very issue that has been plaguing me lately.  while sonar seems to run fine on win10, if I use an electronic drum kit to trigger steven slate drums in sonar, the latency is around half a second (awful).  otherwise things seem to run fine.  I will try setting the ignoremidiintimestamp to 1 to see if it helps.

tenfoot
Interesting Rob. 6 to 8 ticks seems to be pretty standard, and good enough for most purposes at least.
 
At around 20 times the cost and half the performance of the ESI, I would love to hear what MOTU had to say about your findings.
 
The only adjustment I am aware of that MAY affect this on a per interface/driver basis is the ignoremidiintimestamp setting in ttseq.ini. Others may know more! 
 
https://www.cakewalk.com/Documentation?product=SONAR%20X2&language=3&help=INI_Files.5.html
 

thanks. no response from MOTU or vendor yet.
 
I tried IgnoreMidiInTimeStamp setting that but it does not have any impact at all. I believe it only applies if you have bigger (!?!) MIDI clocking issues with the clocks drifting seriously apart (it's a rather old feature) ...
 
 

scottdh
thanks so much for this info!  I love recording but my computer skills lack severely.  I use a roland octa-capture and this is the very issue that has been plaguing me lately.  while sonar seems to run fine on win10, if I use an electronic drum kit to trigger steven slate drums in sonar, the latency is around half a second (awful).  otherwise things seem to run fine.  I will try setting the ignoremidiintimestamp to 1 to see if it helps.

well, what I assessed only applies to MIDI.
 
when talking about playing a sample lib via e-drums you also need to consider audio latency (which will have a much bigger impact) ... and with half a second delay you need to check your system as regards ASIO buffer size (make it as small as possible when trying to trigger via e-drums, and globally disable all Sonar FX) ... even then you might not get sufficient performance (as for proper drumming you'd need a total latency of a few msecs i.e. possibly requiring one of the newer thunderbolt super low latency interfaces). I had tried to do something like you aa while ago (triggering Kontakt drums via a Roland TD-20 kit) but despite low latency (audio ~10ms plus MIDI ~3-4 msec) I could never get a "natural" feel due to the latency still being too much ... the solution was to record everything while monitoring directly on the e-drum kit (i.e. route your click and backing tracks from the DAW to your drum module), record the MIDI and the remap to your sample lib ...
 

Rob[atSound-Rehab]
 
I tried IgnoreMidiInTimeStamp setting that but it does not have any impact at all. I believe it only applies if you have bigger (!?!) MIDI clocking issues with the clocks drifting seriously apart (it's a rather old feature) ...

 
Yes - it was a shot in the dark. I think I last played with it using a midiquest 2 port se somewhere between widows 3.1 and windows 98!
 
 
 

scottdh
thanks so much for this info!  I love recording but my computer skills lack severely.  I use a roland octa-capture and this is the very issue that has been plaguing me lately.  while sonar seems to run fine on win10, if I use an electronic drum kit to trigger steven slate drums in sonar, the latency is around half a second (awful).  otherwise things seem to run fine.  I will try setting the ignoremidiintimestamp to 1 to see if it helps.

Hi Scott. As Rob said this is a different issue to the one you are having, which is more likely caused by the audio latency of your system. Make sure you are using asio drivers for your interface, then try reducing the buffer size by clcking on the asio control panel button under edit>preferences>audio>driver settings.

ah ok - thanks so much!

Just tested the ESI M4U XT, which is the bigger brother of the superb performing MIDIMATE ...
 
ESI M4U XT (win default driver) => offset: 8 - 12 ticks (2.08 - 3.13msec) => jitter: 4 ticks (1.04 msec)
ESI M4U XT (ESI driver)           => offset: 8 - 11 ticks (2.08 - 2.86msec) => jitter: 3 ticks (0.78 msec)


steady offset/latency ... lowest jitter ... like it ...