oh another thing you can try is to get one of the midi interfaces that has hardware midi timestamping in it. There are a few. however, I'm not sure which ones have drivers that will get those timestamps all the way into Sonar.

I use a MOTU Midi timepiece, which I believe *DOES* have hardware timestamping in it....and once upon a time I believe I asked MOTU about whether or not it sent the timestamps through the driver, etc..and they said yes it did..... so in theory...when I hit a midi key...the minute that MOTU hardware gets the midi event, it timestamps it and then the driver and Sonar can add it to the track in its own good time, with something that is very close to when I originally played it. However I have never actually tested this or confirmed with Cakewalk that hardware timestamping from the MOTU MTP is actually being used properly by Sonar. Nonetheless, that is really crucial to have one of those if you are doing real time performances.

If you are mostly programming stuff and its jittering on playback, I'm not sure what to tell you. Try longer buffer settings and freezing your tracks whenever you can.

This became a concern for me a couple of years ago, and I ran a series of tests to prove to myself that my MidiMan MidiSport 8x8s USB MIDI interfaces were introducing jitter into my MIDI timing.

The results were somewhat surprising.

There had been some online discussion about the fact that hardware sequencers and drum machines were known for their tight timing, so I hooked up my old Roland TR-505 to do some A/B/C-ing. I used the TR-505, using its internal sounds, as a sequencer and recorded it as audio in SONAR. I also used it as a sequencer triggering the sounds in my XP-80 (direct MIDI cable), and recorded *that* audio in SONAR. I also used the TR-505 as a sound source only, using SONAR to trigger its sounds via MIDI, and recorded *that* audio in SONAR. I always used separate computers for MIDI and audio just to keep the playing field level.

I also ran a quantized vs. unquantized test.

Just for kicks, I hooked up an old parallel port MIDI interface, as well as an old serial port MIDI interface, and did comparison tests through those interfaces as well.

What I found was that a PC's MIDI jitter, regardless of interface or type of bus, regardless of Windows version or age of computer, was fairly consistently within a 2ms range at a 960ppqn setting. Contrary to popular misconception, the USB interface was not any more jittery than the serial or parallel interfaces - apparently MidiMan has gotten their drivers to a point where the timestamping renders the MIDI stream as reliable as it would be through any other type of bus. This is not to say that the MIDI timing was always fluctuating by 2ms - what I mean is that the most it would fluctuate by was 2ms.

As noted by some of the other user posting in this thread, reducing the ppqn resolution in the sequencer had the potential to reduce the jitter somewhat, but there was still a "jitter floor" that I couldn't get below, and it seemed to be independent of whether the MIDI data was going into or coming out of the computer.

The TR-505 used as a hardware sequencer was, of course, rock solid. No significant jitter that I could measure in the waveforms. I've heard that the Akai MPC-series drum machines share this characteristic, and this is why some producers still maintain that the MPC's "feel" better than a computer.

The bottom line, though, was that the MIDI jitter was indeed present, but not as significant as I would have thought. I did *not* in fact prove to myself that the MidiSport was as problematic as I had thought. With the proliferation of softsynths, it's less of an issue, especially with quantized tracks. Anything that stays within the computer for sound generation isn't subject to the MIDI interface's jitter. However, anything *recorded into* the sequencer via MIDI can have some jitter. I do find that I quantize on computer a bit more than I used to with hardware sequencers. I also find that I generally want to quantize recorded MIDI tracks on the computer, even though I'm usually happy with the timing of keyboard parts that I record straight to audio.

It would be wonderful to see some kind of MIDI 2.0 standard that addresses this issue. For the time being, I, like you, am stuck with the workarounds that we have for making our MIDI timing sound the way we want it to once it's recorded.

Thanks for sharing that!!!

FWIW, The real culprit here is not the midi standard..its the operating system. Because of the way XP and OSX are designed there are certain limitations that require the OS to defer one job in order to finish another, etc.. Even if there is a 1ms timer in the OS, a software program does not have any garantee that it will be able to do what it needs to do every millisecond.

Getting a little technical, in Windows there is a timer that has historically been used, called a Multimedia timer. It is supposed to have 1ms accuracy. However, experiments with this timer have shown that it jitters all over the place in real world situations. Some tests even showed it like +-15ms...yikes! That was a few years back though before XP. In addition, if the software using it is not careful, then GUI use and such can make things even worse.

Some developers have managed to tap into a poorly documented timer that is available in the DirectMusic Api, part of DirectX, which they claim is more solid, but its not really proven to be the case. The thought is that MS did the midi handling for DirectX deeper down in the kernel to ensure solid timing.

What really needs to happen in vista is for Microsoft to move midi handling down into the kernel as they did for some audio stuff. Unfortunately they basically did nothing in vista related to midi. Who needs midi to play Halo?

Anyway, back on topic...RTGraham, I would really be curious to hear if you ever tried using a midi interface that has hardware level timestamping in it. I was not aware that the Midisport 8x8 had hardware timstamping, but maybe it does and maybe that explains the adequate performance you got...or perhaps it does not...and you might be able to get even better accuracy with one that does, at least for incoming midi from your keyboard controller. I'm not sure if midi timestamping is actually used on midi interfaces such as the MOTU, for outgoing midi streams to external midi devices.

This is a subject I would REALLY REALLY love to hear something from cakewalk about.

I know I have had absolutely terrible experiences with USB midi interfaces I have tried and some others that weren't half bad. But I absolutely have been without any question satisfied with the parallel port one I'm using now from MOTU.

I'm just glad to hear that I'm not crazy.

That all makes sense, dewdman42.

I would love to have tried the same tests with something that has been advertised to have hardware timestamping... at the time, the only interfaces I was aware of that publicized timestamping were the MOTU interfaces - but my understanding at that time was that you only had access to the benefit of the MOTU's most accurate timing if you were also using Digital Performer (which I couldn't do on a PC). The Emagic Unitor series also have a reputation for being very solid. I wonder if anybody's ever done a MIDI interface timing shootout.

Interesting thread. Midi feels a little sluggish to me too nowadays. My Roland Fantom has a 16 track midi sequencer (I think it's only 192ppq), and it feels more accurate than PC recording.

BTW, there was something of a standard in Roland's MPU-401's 'Smart Mode', which would receive, buffer and time stamp midi input events in the hardware, and trigger interrupts to notify the PC sequencer that there is data available. Maybe the new MIDI 2.0 standard can borrow some from the ideas Smart Mode midi input handler in the MPU-401.

It also depends on what meterial you will be recording to midi. By introducing "slight" quantization switching from 960 to 480 or 240 or whatever on the ppq side depends on the tempo and the material being presented. When playing in midi drums from my td-20, recording the midi, I want to be able to get the resolution of a press roll, which may or may not be on any "real" beat divisions. Going down to 240 ppq at, say 90bpm, can start to get a little too quantized for that sort of thing.

If I am just going to be playing down to reasonable divisions, I can switch this down to a lower level and make it a lot easier on myself because this "quantization" happens at the midi note placement level. Not including the jitter factor at the higher ppq, you are going to automatically get a slightly tighter recording at the lower ppq beacuse of thie quantization - or if you are a bad play, it may place things on the "next" or previous division from where you intended it.

Thinking of the hardware devices, and their built-in sequencing, I have to think that their resolution is significantly lower - especially when thinking of something like an Alesis HR-16 or Sr-16 or something in that age. Not sure about the MPC...

in fact, I just looked it up - an mpc2000 runs at 96ppq. Yep...there's definitely some automatic fixing happening at that level! Even if you are not acccurately putting stuff in, there's a certain amount of placement that is happening on your behalf. MPC4000 has 960ppq. Alesis SR-16 = 96ppq; Roland Fantom = 480ppq ; Korg Karma = 192ppq

So how much does this say about the "feeling" that these are tighter devices? I don't know - try to turn down the 960ppq (default) in sonar and see if you don't suddenlt feel like a better player"!

Are you sure that Sonar stores it's internal MIDI data as integer based PPQ (96,120,480,960,..) ?

I though that most daws where storing this info as floating numbers PPQ (1.0), and the "standard" PPQ settings where only used for display, at least that's the way it works in other apps.

Spare a thought for the poor Cubase users. What timing they put in, they have little hope of hearing it played back. I always find it funny when I see people recommending going back to the 'tight' timing of the Atari ST and early Cubase. I had it, I worked with it for years. The timing on the atari cubase was as tragic as the timing on the current Steinberg offerings. At least in those days they had the excuse of the vehicle not having much 'under the hood', but with current PCs there is absolutely no excuse. Cakewalk has always had above average midi timing imho, nothing to complain about really.

One thing to bear in mind is the midi timing is a function of both the midi interface driver, and the sequencer itself. Logic 5.51 on the pc is unbelievably literal with how it plays back what you put in, but even with it, using a cheap USB midi interface you can still experience random lag and jitter up to 5ms. Ironically the slower serial port midi has always been tighter, but finding serial port devices isnt' easy these days. My recommendation is always to use the midi interface on your PCI audio card (e.g. RME HDSP9652) before using any other ports that you have, as PCI is almost always tighter and more reliable. USB works, but it's never gonna be as tight unless you have time stamped drivers working in co-hort with a host that uses that time stamp, like AMT or Steinbergs equivalent.

ORIGINAL: dstrenz

Interesting thread. Midi feels a little sluggish to me too nowadays. My Roland Fantom has a 16 track midi sequencer (I think it's only 192ppq), and it feels more accurate than PC recording.

BTW, there was something of a standard in Roland's MPU-401's 'Smart Mode', which would receive, buffer and time stamp midi input events in the hardware, and trigger interrupts to notify the PC sequencer that there is data available. Maybe the new MIDI 2.0 standard can borrow some from the ideas Smart Mode midi input handler in the MPU-401.

Wow - the MPU-401.
I still have a Voyetra OP-4001 (an MPU-401 equivalent) plugged into an old computer in storage - I break out that machine every now and then (more rarely nowadays) when I need to use an old algorithmic composition program, or access sounds in an old patch librarian, both of which only ran under DOS.

I did try to program for the OP-4001 / MPU-401 once, as a side project. I never got the program to process MIDI properly in realtime, but I do recall what you're saying about Smart Mode. That thought, along with the apparent success of manufacturer-specific hardware / software timestamping solutions, seems to suggest that if a MIDI 2.0 spec does ever materialize, it should standardize hardware / software timestamping across the board, so that any interface from any manufacturer will achieve that level of timing stability within any MIDI host.

Well, enough technophizing - I've gotta get back into creative mode.