ORIGINAL: dewdman42

So there are two seperate questions. PianoDano is talking about recording midi parts that are played on a midi controller and that he doesn't feel it is accurate. That is one half of the question. The other half is, if the notes are painstakenly edited to be exactly where they need to be, will sonar play them back through plugins, every time, as they are supposed to be, with rock solid timing..particularly during mixdown or track freeze?

Once the MIDI data is in the right place in the piano roll, the timing will remain accurate and stable when driving softsynths. Since the plugins' audio is rendered within SONAR itself, and the MIDI data never leaves the program to go through any kind of driver translation, it's not subject to the clock issues we've been discussing. Softsynth playback and rendering will remain sample-accurate. It's only coming in from, or going out to, external MIDI devices that the issue comes up.

ORIGINAL: brundlefly

Hmmm... Many opinions, few data points. I did quick test...

(edit)

Average round-trip delay was 11.1 ticks = 7ms...

(edit)

But here's the kicker: Standard deviation of the half-a-round-trip values was 0.5ms (less than 1 tick. So "jitter" is basically a non-issue in this test.

(edit)

...I would say that anyone who can actually feel/hear a significant MIDI timing issue on his/her system probably has a system-specific configuration/performance problem that is not inherent in either the OS or the application.

The tests I had run in the past were similar, with similar results. As I mentioned in my first post in this thread, I measured the MIDI jitter at a much lower value than I would have expected. As pleasing as those results are, though, even a 1ms jitter is enough for a seasoned professional musician with decades of practicing and performing experience to *feel*. And that's the important word - *feel*. We're not talking about whether a musician who uses SONAR can tell you exactly how many millionths of a second that piano note they played is off from where they thought they played it - we're talking about whether the playback *feels* like the original performance. I've been doing this long enough to know that I can definitely feel the jitter (though I've learned to ignore it, fix it in the piano roll, quantize, or use sounds whose attack characteristics mask the jitter somewhat), and long enough to also know that more people can perceive more subtle musical details than most of us realize or give them credit for - they're just not trained to articulate in musical or mathematical terms what they're hearing or feeling.

I would *love* to see a day when MIDI jitter disappears, and I can trust that whatever I record via MIDI will truly play back exactly the way I performed it - and feel the same. This business of piano roll editing and quantizing makes me paranoid about my technique and rhythm sometimes - occasionally I record keyboards straight to audio just for the satisfaction of accurate playback. Again, I'm not saying my system has huge MIDI jitter - it's in a similarly low range to what you're describing - but that doesn't mean that I don't notice it.

No one seems to have mentioned it but Have you investigated the TTSEQ. ini file variables as per the help file? Does tweaking these settings have any effect?

>> something so basic has not been addressed by the designers.

Which 'designers' would that be, Nick? Part of the problem - is that no single designer can possibly control all the stages that handle MIDI events.

MIDI timing is affected by many many factors:

• Quality of the keyboard controller software implementation (if you're recording live MIDI played on a keyboard)
  
• Quality of the MIDI interface driver (PCI, Firewire, USB drivers all have different potential pitfalls).
  
• Whether the driver supports the DirectMusic core API (which supports high-precision timestamping, if available) - or just the original 'MM' API (which has no support for timestamping at all)
  
• Whether the host app (e.g. Sonar) does anything special (e.g. at kernel level) to keep various Windows gremlins from further messing with the timing of the MIDI events - as delivered from the MIDI interface driver.

My point? If the MIDI timing has been compromised by the time the events reach Sonar, there's damn-all that Sonar can do to restore the compromised timing. Which means -- pick your MIDI interface and controllers carefully, so Sonar has good-quality MIDI data to work with.

FWIW - various people have tried to address this over the years (I was one of them, back when I was on the MMA Technical Standards board). The obstacles - both technical and political - proved formidable. For a overview of the technical issues -- see http://openmuse.org/transport/fidelity.html . You might also be interested in a paper I wrote: "System-Level MIDI Performance Testing", available from http://openmuse.org/noncpl/MIDIWAVE-ICMC2001.pdf .

Finally - the IEEE1394 standard for MIDI transport does provide some level of timing guarantees (roughly "as good as a perfect MIDI-DIN cable"), and also keeps MIDI events tightly synchronized with audio traffic. Stock USB does neither (There are no timing guarantees whatsover for MIDI event transport, and USB handles audio and MIDI using two completely different protocols (isochronous transfers for audio, background transfers for MIDI) - which means audio and MIDI traffic can easily drift in/out of sync with each other). PCI-based interfaces -- also have no explicit synchronization between audio and MIDI traffic, but tend to do pretty well even so - if the driver designers know what they're doing.

Personally, I would love to have systems that keep MIDI jitter to very low levels. Hopefully, some future standard will make it possible.

- Jim, notorious MIDI curmudgeon

Edit: fixed broken links (my bad)

ORIGINAL: jsaras

Although I haven't analyzed this to the depths that many people here have, I've noticed that using the audio metronome with MIDI is whacky. When I open up the editor it seems that I'm always playing ahead of the beat. However, if I use a soft synth for the metronome (Stylus), my playing is exactly on. I can't believe that my playing would the problem here...?

There are supposedly some known issues and work arounds for the audio metronome in Sonar. I can't remember the details, but so some searches on the forum and you will find. The problem there is more related to the metrenome then to midi timing per say.

I know for my part, I don't think I am so sensitive to a millisecond or two of "jitter". However, latencies over 5ms drive me absolutely insane, especially if they are not maintained at exactly the same latency. In other words...if it jitters a bit, sometimes 5ms, sometimes a little longer...or shorter...then I can feel it and it drives me totally crazy.

ORIGINAL: dewdman42

Some insightful posts from everyone. Jim, those openmuse links seem to not work?

Hmm.. Some turkey (me) allowed trailing periods to mess up the link. Sorry about that

- Jim

ORIGINAL: brundlefly

Personally, I would love to have systems that keep MIDI jitter to very low levels. Hopefully, some future standard will make it possible.

Hey Jim, I'm curious, with your experience on this, what would you personally propose is an acceptably low level of jitter. From everything I've read, jitter of no more than 1ms would be good enough for anyone if that were the outside limit, and MIDI-Audio synch were maintained at the same level of precision. It's been suggested here, however, that even 1ms is not good enough for top players. What do you think?

Rules of thumb: 10 msec max latency (delay from key-press to hearing the sound, if you're playing live).
1 msec max peak jitter (e.g. delta between expected note onset and actual note onset)
Smart folks at CNMAT advocate the same limits...

Personally, I'd rather shoot for a ceiling of 1/3 msec (330 microseconds) peak absolute jitter (say, +/- 160 microseconds jitter). For reference, that's about the transit time for a single byte of MIDI data over a MIDI-DIN cable.

The 1/3 millisecond limit - is about what MOTU claims for their MIDI Time Stamping interfaces, but I haven't tested it. If MOTU supports the Windows 'DirectMusic Core' API -- and Sonar uses it -- then you could probably get about that level of jitter. Those are big IFs, by the way -- they weren't true a couple of years back (don't know if they are now). Also FYI -- MOTU interfaces that I've tested in the past (MIDI Timepiece 2, with direct serial connection, not USB) -- had excellent jitter, but rather large latency (10+ milliseconds). Since other parts of the 'MIDI event chain' also contribute latency (MIDI keyboard, MIDI cable, Sequencer host...) -- the 10+ msec latency contribution of the Timepiece tended to produce a total system latency of 15-20 msec -- which is only borderline-tolerable. Hopefully MOTU has improved that, now that softsynths are so popular...

Personally, I consider myself to be having a very good day if I can consistently play within 5-6ms (8-10 ticks at 960PPQ) of where I want to be. Most of the jitter I experience is due to coffee.

That may be true if you're playing a single note at a time, listening to a click. However -- if you're playing a multiple-note gesture, you can do way better than that. Multi-note gesture? Drum flam, arpeggiated guitar or piano chord, grace note, etc. When you do that - you are producing a cluster of notes, not a single note. The onset of the first note in the cluster might vary by 5-6 msec (though you can probably do better than that) -- but the relative onsets of the other notes in the cluster (inter-onset intervals, to be technical) can be controlled down to 1 msec or better. Studies have shown that musicians can hold their hands 'just so' and let it drop against a keyboard, or drum, or brush across a set of guitar strings -- and have precise, repeatable control over the timing relationships between notes in a cluster.

What does this have to do with 1-2 msec jitter, if you can't control the absolute location of the note cluster any more closely than 5-6 msec? Small amounts of jitter can 'distort' the intra-cluster timing relationships -- and change how the cluster "sounds". It can wreck the sense of being "in the pocket". Since these are human-controllable timing relationships (yes, you can learn to 'ripple a chord' with that degree of control) -- I've long argued that MIDI sequencers should be able to faithfully reproduce those nuances. But, that's another story....

Here's a quote from the paper I mentioned. Sorry about the stuffy/academic/ubergeek tone - that's what happens with research papers:

Source: http://openmuse.org/transport/fidelity.html

A number of perceptual studies have shown that for streams of individual audio events, timing jitter on the close order of one millisecond can be audible, particularly in the context of rhythmically complex and syncopated ensemble music. [Iyer, Bilmes et al, Lunney, Michon, Schloss, Van Noorden]

[Moore] argues convincingly that time intervals on the close order of 1.5 milliseconds are both audibly significant and controllable by human performers in common musical situations. Consider a sequence of sounds, each consisting of a pair of clicks separated by a short delay (1,2,3,4… msec). Each successive sound has a distinctly different and predictable pitch. The ability to identify musical timbres is strongly linked with their attack transients. If a paired click, as discussed above, were used as the attack transient for sound with much longer duration, the delay between the two clicks would play an important role in determining the timbral identity of the sound.

This phenomenon is particularly significant when grace notes, flams and other musical decorations are played. For example, a pianist plays grace notes by extending one finger slightly before another, and moving the wrist as the hand descends so that the first finger strikes the keyboard slightly sooner. A skilled pianist can reliably control his or her hand geometry so that one finger is about 1 millimeter lower than the other. This corresponds to a time interval on the close order of 1.5 milliseconds under typical playing conditions. While the absolute time position of a particular gesture may vary 10-20 milliseconds (or more) from one performance to another, the relative interval between the grace note and the associated note is far smaller, and quite repeatable. As explained in the preceding paragraph, even small variations in such inter-note delays are quite audible under these circumstances.

In order to preserve the rhythmic integrity of grace notes and other musical decorations, timing accuracy of 1 millisecond or less is needed. Jitter above this threshold can audibly degrade the reproduction of a musical performance.

- Jim

ORIGINAL: jsaras

When I open up the editor it seems that I'm always playing ahead of the beat. I can't believe that my playing would the problem here...?

Actually, I wasn't aware of this...its good to know. I always thought it was me. I've even experimented with a laid back playing style to work on my 'timing issues". I don't sweat anything at 1ms, but above 2ms is definitely noticeable.

ORIGINAL: dewdman42
Is there ANY midi sequencer that can truly get sub-millisecond timing correctly during record?

I don't know -- I haven't done any serious testing since about 2000, and that's a looong time in sequencer-land.

It would be interesting to test the hardware sequencer built into the Korg M3 (480 ppqn resolution), but I don't think Korg will loan me one just for that.... The Akai MPC boxes have a sterling rep (I've never tested them). FWIW, I once helped develop a hardware sequencer that had sub-millisecond accuracy, by our in-house tests (Korg Q1; never shipped... a very long story, very long ago). If we could do it, I'm sure someone else could.

Ask Martin Walker (SOS) He's likely to know if anyone does....

- Jim

Thanks gentlemen.

Before the "how dare you dis Sonar" crowd jumps in, I am really glad that this is being discussed. Without getting to much into the whys and wherefores of my distaste for this issue and the audio only diehards unequivocal support, no matter what, I had just about given up on it ever being discussed seriously here. But lot's of folks have been aware of it for a long time. I know that some pretty good players have had issues with this. In my mind, it is truly weird how the old 1984 Commodore 64 running 1st generation software did much better and certainly the old Roland MC500 introduced in 1987 was just rock solid at far less resolution.

I nearly always sequence while rolling tape at the same time. Fine drummers on a high end Roland electronic set, piano players on the Yamaha midi grand, keyboardists on the Motif also (notice all external so far) and the sequenced results are often disappointing. The feel is different. Behind, ahead and everywhere in between. Enough to drive this dico era musician that played with horns for so long totally off his rocker.

For soft synths Realguitar, EWQLSO, Colossus, and others available here. I have taken Realguitar tracks, tweaked them to where they sound so realistic I could have sworn I was in Nashville, frozen the track and couldn't believe it was the same track playing (as in wth?). I think the bakers have been too busy too long with all the audio upgrade versions to really fix this. I know it has been going on at least since Pro3. I suppose if the masses are happy, Cakewalk must have done figured right. The problem is still there though.

ORIGINAL: Jim Wright
It would be interesting to test the hardware sequencer built into the Korg M3 (480 ppqn resolution), but I don't think Korg will loan me one just for that....

How would one go about testing that, Jim? Is special testing equipment required? I'd like to test my Fantom which also has 480ppqn res.

Maybe all of this is why so many producers still sequence on MPCs, Roland MVs, Korg Workstations, etc...

What a shame that all of this progress in technology has actually contributed to MIDI timing becoming worse over the years. One cause: Most developers probably don't know what a "tight" record even sounds like. Maybe they need to go and (re)visit some of the golden days of tight studio-musician records, such as the later Steely Dan records, the Quincy Jones records, the Jay Graydon produced records. Those are just a few examples. Obviously there are many more from many eras. But those certainly represented a time when "time" was critical.

Thanks for the continued great input everyone! Hope I can find the time to read those articles. Hope even more that Cakewalk will turn their attention to MIDI timing for the next Sonar release.

When I first started using Sonar (Sonar 2), I had midi timing problems where midi timing would drift and midi wouldn't seem to play as exactly as I inputted the notes.

Now Sonar's midi timing seems fine to me. I can't tell a difference between Sonar and the MPC. Things I did:

1. Lowered my midi buffer to 100ms.

2. Kept my midi interface drivers updated (Motu midi xpress XT).

That's about it.


IMO, Midi timing seems to have improved to me. In the 90's my MPU 401 compatible interface had horrible timing problems. Never knew if it was the computer, software or interface though but I don't really think old computers or hardware sequencers is the answer.


On Sonar and Reason, midi timing is rock solid to me.

On Ableton Live and P5, I had timing problems on both. Minor timing problems on Live, some major problems on P5 though but I'm not sure if it has been fixed or not.

ORIGINAL: jlgrimes

but I don't really think old computers or hardware sequencers is the answer.

Yeah, if you think about it, the computing power in a circa 1989 MPC-60, still known to be one of the most solid hardware sequencers, must have been exponentially less than the dual/quad core PCs of today. Combined with the fact that MIDI is very lite on CPU cycles, it can't be the PCs themselves. It must be the software and the way MIDI is handled as part of all of the other housekeeping tasks an operating system must deal with on a millisecond to millisecond basis.

Its not the hardware. Its the Operating system. If you have a custom built hardware box you can control every instruction that happens in real time and ensure the timing you want. In a multi-tasking operating system such as Windows XP, OSX, linux, etc... any software program that is running is sharing cpu time with other processes that have to do what they have to do. The OS provides timers, interrupts and other mechanisms to try to give software developers an opportunity to interject on demand and do what they need to do, but this is not exact or perfect control....and so even 1ms timing cannot be guaranteed on top of all the popular Operating Systems. A drastically faster CPU *MIGHT* reduce the contention of these various tasks which could theoretically improve the DAW's ability to make completely effective use of the multimedia timer...but this is not the main constraint.

Tangent:

It actually used to be possible with win98 to create tighter midi timing because there was a hackish backdoor that could be exploited in win98 to THUNK into a 16bit DLL, which had the fortunate byproduct of forcing that 16bit DLL to execute immediately. By this means midi programmers could force a midi driver to get attention and timestamp incoming midi events via the 16bit DLL....basically trumping anything else the OS or software was up to at the time. However, with the release of NT4 and Win2k, Windows became a more true multitasking 32bit OS and this back door capability was lost. In fact for a while, midi timing in NT and Win2k was absolutely terrible and people were sticking with Win98 for that reason. Microsoft eventually got Win2k working better and definitely they got XP working a *LOT* better...but its still probably not quite as rock solid accurate and tight as a properly and cleverly code Win98 application could be in terms of midi. Of course there are many other benefits to XP and true multi-tasking that far outweigh the less-then-optimal midi timer accuracy of XP. Plus, who wants to deal with Win98 crashing all the time?

Uncareful programming can result in much much worse than 1-2ms jitter actually. That is why Live is now being improved. IMHO, anything close to 1-2ms timing accuracy on XP or OSX is about as good as its gonna get on a DAW and not worth crying about any longer. If you want better, start crying to Microsoft and Apple, but I doubt they will ever change it in the OS because relatively speaking we are a small crowd.

I just spent a bit of time researching some hardware sequencers out there. Most all of them are 96 ppq, these are the ones purported to be rock solid timing. Ok...perhaps so,, rock solid, but 96PPQ is 5ms per tick at 120bpm. That is not exactly any better than the reports we are getting from some here about Sonar handling within 1-2ms of jitter at 960ppq. By the way, 960PPQ = 0.5ms per tick.

See what I mean? Are we looking for the wrong thing here in terms of the problems some people are reporting in Sonar midi timing?

I only found a few newer hardware sequencers like the Akai MPC-4000+ ($2800) and the Roland MC-909 which are 480ppq (1ms per tick and hopefully no jitter). Those are probably about the best there is right now, but not inexpensive. All the old ones and also most of the new ones are only 96ppq and personally I think if Sonar really is giving you 1-2ms of jitter at 960ppq, then Sonar will be tighter then those old hardware boxes...with one exception....a quantized performance would sound tighter on the 96ppq hardware box since every note would land exactly on a tick and have zero jitter, while sonar might float around on playback by 1-2ms...maybe?

However the stuff people have talked about so far as mattering are things which should not be quantized, so the old hardware boxes would not be any better than Sonar, in fact they would be worse. Sounds like the top of the line MPC or Roland groovebox might be better...but I sure can't afford one.

The problems that I keep hearing people talk about on here I think are mostly much greater than 1-2ms of discrepancy. They are blatantly bad midi timing glitches. That implies to me they are having DRASTIC midi timing problems under certain circumstances and those are the situations we need to identify and try to get Cakewalk to fix. I do not think Cakewalk can do anything about the 1-5ms range of jitter due to limitations of the operating system.

I've heard a scattering of stories here, but one common theme seems to be related to audio buffer sizes and I'm wondering if delay compensation is a bigger culprit here with some of these stories about seemingly drastic midi timing problems.

ORIGINAL: dewdman42

ORIGINAL: pianodano
For soft synths Realguitar, EWQLSO, Colossus, and others available here. I have taken Realguitar tracks, tweaked them to where they sound so realistic I could have sworn I was in Nashville, frozen the track and couldn't believe it was the same track playing (as in wth?).

Yikes, not good. That infers that Sonar is not handling midi to soft synths without jitter of some kind. Perhaps bugs in delay compensation? Not sure if the problem is happening while you're playing back the unfrozen midi tracks or if the problem happens when you free them. I would think that freezing should render perfect results..but if you can't hear it correctly while editing in the PRV..what difference does it make. They both need to be spot on and there is really no excuse for it not being so.

Certainly you can align any midi track in ppv if you want or need to. But it often looses the original (as played) feeling. What I see is it's the actual played part that is captured incorrectly. I am fairly confident it's not the clock in my case.

In the instance quoted I am referring to a tweaked (perfectly satisfactory) midi track which is driving the softsynth and what then happens to the audio after said audio is frozen. Realguitar is a perfect source to test this because every note has a strong attack. It may play along perfectly for a while and then suddenly 2 or 3 notes get screwed up. Somehow during the freeze process the audio becomes slightly mis timed and it usually continues to get worse. YMMV. It is a part of the frozen track and will always be and start in the same place - Not randon.