Interesting recap.
I'm still inclined to believe that it *is* possible to *feel*, if not hear, even such subtle jitter issues as .5 ms. However, you make some good points.

I'm still inclined to believe that it *is* possible to *feel*, if not hear, even such subtle jitter issues as .5 ms. However, you make some good points.

I think that's a bit optimistic, that's like saying you can hear the difference of two signals one being 6 inches away and the other being 9 Inches away from the Speaker. Most people can't tell the difference under 5 Milliseconds, even the Golden Eared ones admit that. There was an article in Sound on Sound a few years back quoting the technology and especially Midi slop and they were talking Microseconds of delay from when you hit the key to when you hear the Midi. I'll see if I can dig the article out.

It is more of a feel issue. But, so.. "feel" is basically your subconcious telling you what it "hears"........

this may be the articles you were referring to from 2002.
which were posted earlier in this thread.

http://www.soundonsound.com/sos/Sep02/articles/pcmusician0902.asp
http://www.soundonsound.com/sos/Oct02/articles/pcmusician1002.asp

Most people are experiencing a lot more than .5ms of midi slop. That is why they can feel it and even hear it. If we were truly getting sub millisecond timing, nobody would be complaining at all. But we aren't. Only people with hardware midi timestamping are truly getting sub millisecond timing. Nobody using Sonar has that option. MOTU makes pretty much the only midi interfaces with hardware timestamping, but they did not build support for it into their windows drivers. Only for the mac Core Audio and only if the actual sequencer makes use of the timestamps.

Not to sound like a broken record here, but if you playback through plugins, there should be zero slop at time of playback. If you insist on using external midi playback devices, then I'm sorry for you, but more slop.

The real issue is about how you record the midi track from a midi keyboard. There is a lot of slop both in the way the events are captured into the track, but even more latency when you talk about the monitoring aspect. The end result is that the connection of playing and feeling is disconnected at best by several milliseconds and can vary (slop) by as little as .5ms variance in some ideal setups to as much as several more milliseconds, which sometimes brings it into the realm of even the most tone deaf schmoe hearing it.

As has been stated, there is not much Cakewalk, Steinberg or anyone else can do about it other than adopt better hardware/software integration where timestamping is done closer to the time the key is pressed on the keyboard.

Today, the best results will be if (A) you use a hardware sequencer that is built into an actual keyboard, like on the Fantom or something like that using built in sounds...so that no midi cables or PC audio latency are involved. Record the midi track there, transfer the midi track to Sonar, then (B) play it back through a vsti plugin.

Otherwise, live with several ms of slop and stop complaining, there is nothing that can be done about it anytime soon. The vast majority of people that are complaining about midi timing are most likely experiencing 5-10ms(or more) milliseconds of slop and could improve their timing perhaps with a more optimized setup. Nobody is getting 0.5ms. The best Windows setups are probably in the 1-3ms of slop range.

Here is an interesting white paper for the strong hearted that want to understand more about audio and midi software technology in general:

http://www.portaudio.com/docs/portaudio_sync_acmc2003.pdf

The bottom line is that most of us are not getting sub millisecond accuracy from midi. Its not even close to that. Its debatable about who can hear it. Its not as debatable about whether there is a disconnected feeling while playing it. But the question I have is that if a good player is instinctually "humanizing" his performance by playing "off the grid" intentionally, then the question remains as to how much midi jitter destroys that aspect of the performance, and which quantizing also destroys? Also, the 960ppqn midi tick grid is a non-musical form of quantization which means that even if every other aspect of midi jitter were eliminated entirely, every midi event still has the potential to be stored in the midi track, inaccurately off by as much as 0.3ms from when it was actually timestamped by the midi driver after all the aforementioned slop. So that is yet MORE slop and worse yet, its almost guaranteed to put the events on non-musical points of time, in terms of that 1ms window, not matter how perfect the player played it on or off the grid...the stored events will not be where they performed it.

In case anyone is interested, there is a Phd that corresponded with me last year when this thread was going full tilt. Here is a project he has been working on related to this very concept. He analyzed some non-midi performances by top players in order to try to figure out what kinds of subtle timing nuances are in the performances of the best available players. This links has a bunch of videos, but there is a link in the middle of the page to read his white paper that explains it.

http://www.tlafx.com/WhatDoesMusicLookLike/index.html

He even used a diagram I did for this very thread as part of a later white paper he wrote and presented at a conference:

http://www.tlafx.com/Papers/JASA07_LindsayNordquist.pdf

The bottom line is that most of us are not getting sub millisecond accuracy from midi. Its not even close to that. Its debatable about who can hear it. Its not as debatable about whether there is a disconnected feeling while playing it. But the question I have is that if a good player is instinctually "humanizing" his performance by playing "off the grid" intentionally, then the question remains as to how much midi jitter destroys that aspect of the performance, and which quantizing also destroys?

I agree that sub-millisecond is not going to happen consistently with the existing technology. But sub-3ms timing is totally feasible (I think I'm pretty much there), and I maintain that the majority of musicians can not - or do not choose to - play with the precision necessary for this to be a problem. I haven't read the white paper you linked in detail, but the following jumped out at me:

"Thus the maximum range for pulse timing variation during this section is less than 600 milliseconds
(average time for the half note backbeat) divided by 8 (mean pulse time multiplied by 1/8th
note duration), or about 75 milliseconds. Most of the pulse time deltas are less than half of
this figure, 35 milliseconds or less. This represents a fairly loose rhythmic style.

This is pretty much the "order of magnitude or more" timing variation (vs. MIDI jitter) in a good musician's performance that I was talking about.

At this point, I'd really like to see some other MIDI/keyboard-playing forumites (especially by those who feel that they are not having significant MIDI or audio timing/latency problems their DAWs) do some personal experimentation and post their observations about how tight their performances are vs. how accurately SONAR can re-create them from MIDI. They should try different recording methods: e.g. local control enabled on the keyboard with direct monitoring of an onboard synth sound vs. echoed MIDI driving a soft synth or even an outboard synth, and record MIDI and audio simultaneously with their audio latency compensation dialed in to sample accuracy. Let's import some more real-world data to this ivory tower of a discussion.

Any takers? C'mon I know we can drive the post count of this thread into the quadruple didgits.

No takers, huh? Well, here's a little test I did using my QS8 as both a controller and as an independent hardware synth (i.e. Local Control OFF). Pretty easy to replicate for anyone who wants to try it:

1. Adjust the Manual Offset in Record Latency Adjustment to compensate for MIDI transmission and hardware synth response delay (e.g. approx. 80 samples at 48kHz for my QS8 connected via ADAT).

2. Set tempo to 62.5BPM, so that 1 tick equals 1 millisecond (at 960PPQ).

3. Without using a click, record several measures of simultaneous MIDI and audio, playing individual staccato notes at random intervals, preferably using a high-pitched, dry patch with a fast attack to facilitate AudioSnap’s location of transients.

4. After recording, use Process/Interpolate to shorten the duration of all the MIDI events to 4 ticks (4 milliseconds), and slide the whole MIDI track back 2 ticks so that the MIDI events now represent a ± 2-millisecond window centered on the original event time.

5. Enable AudioSnap on the audio track, tab to the first transient marker, and zoom the time scale so that the MIDI events are approx. 1” long on the screen. Then tab through the transients and note where they fall relative to the centers of their corresponding MIDI events.

In my case, with a hundred notes played in about 30 seconds, all the transients fall well within their respective ± 2-millisecond windows. And note that what little “slop” there is includes: two-way MIDI Jitter (because I’m playing the synth via input echoed MIDI), external synth response variation (pretty fast and tight on the QS8), and AudioSnap transient location errors (not zero, but not too bad with the sharp, well-isolated transients in this test).

This is a pretty dang reasonable result if you ask me.

ORIGINAL: brundlefly

No takers, huh? Well, here's a little test I did using my QS8 as both a controller and as an independent hardware synth (i.e. Local Control OFF). Pretty easy to replicate for anyone who wants to try it:

1. Adjust the Manual Offset in Record Latency Adjustment to compensate for MIDI transmission and hardware synth response delay (e.g. approx. 80 samples at 48kHz for my QS8 connected via ADAT).

2. Set tempo to 62.5BPM, so that 1 tick equals 1 millisecond (at 960PPQ).

3. Without using a click, record several measures of simultaneous MIDI and audio, playing individual staccato notes at random intervals, preferably using a high-pitched, dry patch with a fast attack to facilitate AudioSnap’s location of transients.

4. After recording, use Process/Interpolate to shorten the duration of all the MIDI events to 4 ticks (4 milliseconds), and slide the whole MIDI track back 2 ticks so that the MIDI events now represent a ± 2-millisecond window centered on the original event time.

5. Enable AudioSnap on the audio track, tab to the first transient marker, and zoom the time scale so that the MIDI events are approx. 1” long on the screen. Then tab through the transients and note where they fall relative to the centers of their corresponding MIDI events.

In my case, with a hundred notes played in about 30 seconds, all the transients fall well within their respective ± 2-millisecond windows. And note that what little “slop” there is includes: two-way MIDI Jitter (because I’m playing the synth via input echoed MIDI), external synth response variation (pretty fast and tight on the QS8), and AudioSnap transient location errors (not zero, but not too bad with the sharp, well-isolated transients in this test).

This is a pretty dang reasonable result if you ask me.

I had done something similar a few years back, which is one reason why this thread is so interesting to me. Unfortunately time constraints are preventing me from trying similar testing with my current setup, but I'd certainly be curious to see other people's results.

perdsonally late this is, i dont see what midi jitter has to do with this whole discussion, or why it is an issue.
midi keying only signals another device to send an audio signal. when ever the synthesier sees midi signal , it spits out some sort of tone. midi is a dc signal that we dont hear.meaning midi jitter is not heard, only timing error is heard. and it is plenty fast enuf as it is only sending typing signals of what we type on our keyboards.
it may help every one to read the wikipedia on the subject, under midi,
also theyre is an official midi site that has schmatic info, it helps when we understand what we are speakething of. at least for me it does, and i'm sure you are all rite, however, i learned something reading midi specs. it seems to me i shud break off the center pin (ground)on the receving side fo tehe cable or the cable that goes into the in port on my midi keyboard or device
acooding to midi specs, ground loops are a commom occurance. breaking off the gorund pin on the the "in" side will oprevent the problem discussed on the official mididi site while continuing to shild the cable. fyi
tty tech wayne out in sf ca usa

meaning midi jitter is not heard, only timing error is heard.

And thus this whole thread.

Announcing that the folks who have been involved in this thread, primarily people who have done pretty extensive testing and measurement of the aforementioned jitter, that they should read about midi out at the wikipedia indicates that you haven't really read the whole thread and why anyone cares.

I am one of those who believe that the amount of jitter present on my system, comparing to the audio being produced by that midi, is within my performance limits, meaning that I was unlikely to be any "closer" to the real thing on a repeat performance of the same thing. At any rate, that puts me on the side of the discussion that believes that a really small amount of jitter/latency/slop, whatever can still work. Some of it is talk for the theoretical sense of it. Some people just want to know if it's on or not. Some people believe if THIS is off, then it's likely that there is other more hidden stuff that is off as well. Some say they can hear the difference.

Whatever the case, I don't think anyone here is in need of a basic midi lesson.

Whatever the case, I don't think anyone here is in need of a basic midi lesson.

Just turn up your MIDI velocity. This will increase the speed of MIDI transmission, which will reduce both the transmission delay and the jitter. I now set all my notes at 127, which is the highest velocity available, and I haven't had any more jitter problems... everything is a little bit loud, tho.