Sometimes I'd count the samples between the midi events: 80, 80, 66, 52, 45, 83, 74, 68. Avg is 1.55ms round-trip (at 44.1)
Another time it'd be twice as much, avg of 3ms round-trip
Sometimes it would be 30 samples or less between events
Sometimes the recorded MIDI events would occur before the outputted events!
Sometimes the recorded MIDI events are late by 4 samples, or exactly on.

I don't understand how you could get MIDI events at these tick intervals. 125BPM is approx. 21.7 samples per tick at 44.1kHz and 960PPQ, and 100BPM is 25.9. You should only be able to have MIDI events on whole-number multiples of these values. What tempo did you use for testing?

Again I was testing in both programs, mostly in Reaper

Okay, I missed that. Maybe Reaper doesn't enforce tick boundaries on MIDI until you quantize it? I'm not familiar with it. It's not that I doubt what you're seeing; just trying to understand what the software is really doing. Obviously having recorded MIDI placed ahead of the sent event isn't right. Makes me wonder if Reaper is doing some sort of MIDI latency compensation. As you mentioned, audio latency compensation should not affect MIDI.

We should probably move this to its own thread, but at first glance this looks like only +/- 1 tick of variation - not unusual at all. Probably due to the jitter of the interface as discussed ealrier in this thread, as opposed to a timing problem with the TD-8. Also it appears that audio is a little over- compensated, assuming the MIDI events were at 2:01:000. This is a little unusual, as the response time of outboard sound modules together with outbound MIDI latency usually makes the audio a little late.

Ok, I'm on page 5 of this thread. and, just wanted to push it to the top again as in my view, this is the most important thread that has ever been on this forum.

Looking back in hindsight, thru the years of my searching for information on these timing issues and just giving up and thinking I was crazy because no one else had the same timing issues. But , then again I'm coming to the realization that, really, it's kind of hysterical to think that human beings could actually assume they could create some kind of hardware or software that could take from the air and/or heart and duplicate it into 1s and 0s and then recreate it.

But then, hmm, tape decks did this. A simple piece of oxide passing along a head sending electrical signal thru all it's thingys , making music, not just sounds. There it was, it had feeling.
WTF is wrong with computers? How can a 15ips tape machine be faster than souped up computer??

I've been with Cakewalk since Dos.
numerous tape decks before that.
After 20 years of trying, I am getting to the point of realization that one basically cannot make "music" with computers.
Or, is it Cakewalk?
Pro-tools must be the standard for a reason. Do they have these kind of issues?

EDIT:
Ok, I thunk about it a bit after my little emotional outburst.
Computers can and are a great recording medium and will record audio quite well.
I guess trying to use it as an instrument via anything midi is where things get screwy.
amazing that midi hasn't gotten any better.

CAKEWALK, Please go hire Roger Lynn to sort all this out. Or, buy his code or whatever it was that he used in his
Lynndrum back in the 80s. I'm guessing that the Akai boxes mentioned in this thread are similiar.

Tim

I never think of Sonar when I think of something to record accurate unquantized MIDI performances on. Is there such a solution in software?

Well, I guess to answer my own question, considering what prompted me to start this thread, it would currently be Ableton Live.

If there's one thing that everyone should be able to agree on in this thread, it's that MIDI jitter is inherent in the technology and the limitation of hardware performance, and cannot be completely resolved through software alone with the existing MIDI standard. Ableton has no chance of being any better than SONAR.

I also want to reiterate that while I contributed to this thread, and found it all very interesting from a technical standpoint, I still maintain that the vast majority of musicians do not have sufficient personal timing accuracy or consistency to justify concern about a tick or two of MIDI jitter (.5 to 1 ms at typical tempos). If you can hear timing issues in a MIDI performance recorded by a properly functioning SONAR installation with a good interface, then the problem likely lies somewhere between your brain and your fingers.

I firmly believe that when you are actually performing, you hear the performance differently than when you listen back to the recorded performance. Your brain is in the groove, even when your fingers aren't.

Try recording the same live performance two or three times, and I predict you will find pervasive timing variations of individual notes from the grid and intervals between notes that are an order of magnitude or more greater than the MIDI jitter in your system.

The delay issues that Timidi is having are a different issue altogether. The cumulative delays he is dealing with due to inadequate audio latency compensation are a real problem.

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.

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

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.

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

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.

Seriously, since this thread bubbles to the surface now and again, I hope the Sonar team will take this into account in the next version of Sonar. If possible to improve, the MIDI recording (unquantized) needs to be more accurate. If Live can do it, then so can Sonar.

Hopefully we will all start moving toward Open Sound Control and be done with MIDI once and for all. Midi is ancient tech (what else do we use today that was in use in 1983?). OSC looks promising and its already being adopted by big name electronica performers to trigger everything from midi events (as a controller) to light shows. Much more effective, accurate and robust than MIDI. I wonder if CW is looking at it?

http://opensoundcontrol.org/introduction-osc

Pianodano, you seemed to change your POV about midway through that post from sincerely supporting old tech, then "relegating it to the back burner". IO think I get what you are saying and to my interpretation, I'll add:

I think the only way a replacement for midi could be workable at all would be one that from the start, not as an afterthought supports midi backwards compatability with some sort of included adapter to be able to "dumb down the signal" for a regular midi device. In this case, as long as compatibility with manufacturer's midi spec isn't a big issue, people with old stuff would continue merrily along and new devices could start taking advantage of new features. The old midi spec could run as a way background process, considering how little is required to run it (in itself, anyway). This would all, of course, need to have major player industry backing to succeed, like from Roland AND Yamaha AND Korg, or whomever.

I still contend that, if the right combination of software and hardware happen to come together on a machine, the actual amount of the jitter that we are really discussing is generally minimal enough for most people - un-noticeable. There are clearly OTHER problems, like the one I used to have on this system running under an M-Audio Omnistudio USB device. My midi and audio were so off from what I knew I played that the feel was noticably sloppy and just "off". I switched to the Layla3g and all is well.

Has ayone here used the "Fit to Improvisation" command in Sonar to line up their Midi and Audio versions of the same track before playing it back?
Clearly you must get it into the track without too many problems first, but to tighten the Midi up to the Audio manually could involve a lot of piano roll editing and time.
Input Quantize the Audio and Midi? Fit to Improvisation?

I need a dedicated audio PC. But since I don't have one, I accept full responsibility for the results of trying to do music work on a desktop PC which doubles for music.