Blades --

dewdman, That's what I do with my Vdrums. If I echo the midi back out, it feels "soft", "squishy" - but I think this is more due to the round trip latency than it is to jitter - it feels consistently like this, not with a variable amount of squishyness.

As far as the 10ms of timing - in a live show? really? I'd think that unless you are using in-ears, it would be a completely impossible feat - 1ms per foot away from the monitor - so say 6 feet to my ear from the monitor and I only get 4ms of playing slop. Seems a stretch. I mean, something like 100 ms+, like Church organists may have to deal with would feel sloppy to the player, but still probably feel fine for the audience.

Latency and jitter are different (as you've pointed out). 10 msec latency is a bit squishy, but manageable; you can still lay down a solid part even with 10 msec jitter. Heck, the latency from the conductor to the back of the orchestra is quite a bit more than 10 msec (farthest players are maybe 20-25 feet away? That's 20-25 milliseconds latency; orchestra players learn to cope).

It's the jitter that kills the performance, not the latency. One fairly-well accepted guideline has been: for the whole system (key press to sound-reaches-the-ear), total latency should be no more than 10 milliseconds, total jitter should be no more than +/- 1 millisecond. Lower values are better - but those are suggested max values for good musical results. (These guidelines are from the 'academic' computer music community - I can give sources on request).

The point about 100 ms+ Church organist reponse time is a funny one. I actually had a Microsoft engineer insist to me that musicians didn't really need anything better than 50 millisecond latency, because Church organists could deal with it. He really did. Repeatedly. This was in around 1999 - he was the main Microsoft guy tasked with USB MIDI stuff. Which may explain a few things...... (Note: this guy was not on the DirectMusic team -- those guys (Todor Fay, Martin Puryear, others) really did know their stuff).

- Jim

However, the drummers were not listening to individual sounds in isolation from all other sounds. Rather, they were listening to drum hits in the context of a solid groove, and noticing that if one (of many) concurrent parts was shifted just slightly - the groove didn't "feel right" any more. This is a totally different kind of listening experience, and people who generalize the "sounds in isolation" experiments to make statements about what people can detect when sounds are not heard in isolation - are making a fundamental error in reasoning.

I just want to say that this is a really good, concise, reasonable and helpful post to give the discussion some context. Bravo, Jim.

It would be very interesting to see some more real-world data on how tight a good drummer can be, referencing each hit to the others around it, and then looking at how tight a whole ensemble can be. Let us know if you find any other references on the Web, Jim. Might have to do a little searching myself.

Dave

ORIGINAL: Jim Wright
However, the drummers were not listening to individual sounds in isolation from all other sounds. Rather, they were listening to drum hits in the context of a solid groove, and noticing that if one (of many) concurrent parts was shifted just slightly - the groove didn't "feel right" any more. This is a totally different kind of listening experience, and people who generalize the "sounds in isolation" experiments to make statements about what people can detect when sounds are not heard in isolation - are making a fundamental error in reasoning.

So, what might the drummers be hearing? I don't know, frankly. I suspect it has to do with how the attacks of different percussion notes overlap and reinforce (or interfere with) each other, psychoacoustically. I believe that something is going on, in the complex web of sounds that make up a good groove, that tickles the human nervous system in good ways when the groove is really in the pocket, and in other ways when the groove isn't quite there.

What a fantastic explanation.
Thanks, Jim.

ORIGINAL: RTGraham

Without getting into my credentials, I'll just say that I'm fairly certain I hear, and feel, the 2-millisecond jitter. To a certain extent, I have probably lowered my standards and forced myself to adapt to the way it feels and sounds, so that I can manage to get through MIDI sessions without losing my mind, but I would love to have it feel better. I actually was already thinking about getting a hardware sequencer, based in large part on this discussion - but then I lose all of the fantastic graphical editing tools I've grown accustomed to. Even though we're a niche market and a small percentage of Microsoft's market share, we still have a right to request that manufacturers create the tools that we need to operate at the best of our ability - and it seems that a software sequencer like SONAR, with the timing integrity of a traditional hardware sequencer but the graphical editing capabilities we've all gotten used to using, would be one such tool. I would consider going to a Pro Tools TDM system, even with it's bloated price tag, to take advantage of what people have described in the way of Digi's MIDI I/O interface's timing stability - but I just don't like working in Pro Tools as much.

Big +1 on that. Bravo! Well said.

ORIGINAL: dewdman42

A few points

1 - You will get MORE jitter if you use 960 PPQ. (huh?). Its true. If you want more reliable timing accuracy, then go with 480, or if you can, go even lower than that. The only downfall of lower PPQ is that you are introducing a very subtle form of quantizing to whatever you record. However, let's do the math:

at 120 BPM, that is 2 quarter notes per sec. That is 1920 ticks per sec, which is sub millisecond.

So right off the bat, changing to 480 PPQ will give you theoretically around 1ms tick timing.

However, what you need to know is that the Windows OS is not even capable of reliably providing timing even that low. Many tests and studies have been done about this. As soon as you try to get down to 1ms timing, or even somewhat higher...the error rate goes up...which is what gives you real jitter. This is particular true while recording your midi track from a midi keyboard. USB adds even more latency and jitter to the mix.

If you could, for example, live with say 5ms ticks, then the jitter is a lot less, because the OS timers can keep up with it more or less error free.

200 ticks per second = 5ms ticks. At 120 BPM that is only 100 PPQ.

Moral of the story, lower PPQ values will give you more reliable and error free, reproducible playback. It will play back more exactly what you see on your PRV. As you raise the PPQ, more and more jitter will be present. The downside is that if you want to nudge notes forward or backward by 1ms or whatever...then you need the higher PPQ and just have to live with the jitter. One situation where you might care about that is if you're doing film scoring or something where you need to line up beats on frames, etc.. Having more PPQ allows you to calculate tempos that are more accurate for those hit points. In that case, you're not using a midi keyboard to record, so the Windows OS crappy timers are not relevant. Also, once the midi track is recorded, if its playing back through a VSTi, then when the track is frozen or a mixdown is done, in theory there should be no jitter. If it has to play back through external midi gear or even using a virtual midi cable inside the PC...then the jitter can be bad and there is not much Cakewalk can do about it.

2 - Cubase is notoriously worse

The point where this all become irrelevant is that I can hear the difference when working at 480 as opposed to 960. It's obviously not as 'open' and flexible.
I'd rather have unpredictable jitter ( if it even exists ... I've never noticed ) at 1920 ticks per quarter note ( yea give me more resolution please ) than be workng at 480.

My sequencer history is as follows:
1) Roland MC 500 Mark II ( clock at 96 ) When it was the only thing available it was tollerable ( but just barely )
Always a compromise between time and velocity. ( i.e. using velocity to compensdate for time )

2) Ensoniq SD-32 ( clock at 120 ?? can't remember ) Same story as above.

3) CWPA9 ..... oooooo .... OK now the timing is alot better ... but still ... sometimes ... something's not quite right.

4) Sonar 3, then 4 at 960. OK. Now, nothing ever bothers me about the clock. I'm using it the same way I would a tape recorder.
I never qualtize anything.
960 is the first time I've ever been able to say that.

ORIGINAL: Blades

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"!

You got it!
Ideally, if you want accuracy to your human performance, you want the highest PPQ possible.
I've dealt with the slower clocks also and I can tell you it's frustrating and very obvious that things aren't being recorded the way they're being played.
If I want something "fixed" then I definately want to have more choices ( more ticks ) as to where to move it.

ORIGINAL: brundlefly

Hmmm... Many opinions, few data points. I did quick test: Set up a MIDI track to send 96 note events at 10-tick intervals at 960 PPQ and 100BPM (.625ms/tick). Plugged a MIDI cable from the Out to the In on my M-Audio Omnistudio USB interface, and recorded the output of the test track. No synths or controllers were involved, just MIDI data making a silent round trip.

Average round-trip delay was 11.1 ticks = 7ms. Assuming delays are equally divided between sending events and clocking them back in, that means MIDI events recorded from a manually played hardware synth might get clocked in 3.5ms (5 ticks) late on average (not including delay between the keys and the MIDI Out on the controller). Not perfect, but I can live with it.

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.

For reference, I ran the same test with the same setup at 96PPQ, giving 96 events at 1-tick intervals. Results were about the same within the limits of the lower resolution. Mean round-trip delay was about 0.9 ticks, and half of that is .45 ticks = 2.7ms, with a standard deviation of about 1ms.

In summary, it does not appear that jitter is a significant problem in this test configuration, and higher clock rates do not have a isgnifcant impact one way or the other. This makes sense, as even 960PPQ is extremely slow compared to system clocks running in the Gigahertz range with a 1000 or more CPU cycles going by between ticks.

I will say, however, like others, that I have had more trouble with MIDI timing errors in the Windows era than with the old MPU-401 hardware interfaces with their onboard clocks running under DOS. But I have always been able to fix these problems with configuration or hardware changes. Based on that experience, and the results of this (admittedly crude) test, 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.

Excellent work. And I agree 100%

ORIGINAL: pianodano

Maybe I'm missing something here but that's exactly what I think should happen if you are aiming for say... the exact beat. But I don't think improved acurracy is the correct term if you're intentionally playing behind the beat and want exactly what was played captured.

Yes. I totally agree.
More ticks = less quantization = more resolution = more accuracy.

P.S.
Don't confuse the term acuracy with lining up exactly on the bar lines.
Accuracy by my definition here means "true to the actual human performance."

Great thread!