ORIGINAL: pianodano
We would never have tolerated errors in timing of the sort I am dealing with now, to be introduced in the shows of old. Much less recordings. My brother and I (I'll just say he is a exceptionally talented drummer that can lock to the clock and not vary) used to argue over shifting latin percussion tracks 1 or 2 ticks behind the beat. That was when we used the MC500 for live work. If someone would like to do the math. Tempo around say 118, 4/4 time, 96ppqn. The difference should be noticeable to most musicans.

ORIGINAL: dewdman42
Did you disable the metronome? Still terrible? Which plugin you using for the bongos? can you render a wav file of the terrible result and post that along with the midi file?

ORIGINAL: Blades


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.

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.

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.

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

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

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.

ORIGINAL: Steve_Karl

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

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

But if you were to move or change the note while in 96 mode, then I bet the timestamp would become quantized to a 96PPQN grid.

ORIGINAL: dewdman42

ORIGINAL: Steve_Karl

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

You missed the point I was making initially and that most of this thread is about.

It is my feeling that if you set the midi resolution to a lower value, then the internal timestamp should not be changed per say, but playback should be quantized to that lower resolution. This smells possibly to me like a design flaw in Sonar. If the PRV is not representing what is actually going to be played, its kind of a lie.