What's with ProTool's MIDI Quantizing??

[mobmusic]

Let's dig a little deeper into this "slip" or "drift" problem some of us are experiencing. I do not have the rock solid timing I expect from ProTools, but I cannot verify this in isolated tests. It always starts when I have full sessions of multiple MIDI tracks going that I solo a percussion part and inevitably hear the "drunk drummer" syndrome (no offense to percussionists).

Here's a rundown of the things I've tried to fix:

- shorten lengths of MIDI cables
- Use the IAC Bus to a software sampler
- Use a MIDI cable out and then directly back into my MOTU Micro Express to control the software sampler
- Use hardware synths with percussion instruments
- Use PCI MIDI devices with onboard percussion sound samples
- Use the IAC Bus to a PCI card with a sampler on it
- Reduce my HW buffer to 128
- Increase my HW buffer to 1024
- Limit the number of extensions in my set
- Allocate more RAM
- Solo Tracks
- Hit play

If I try this on measures of 16th notes, 32nd notes, and 64th notes quantized straight to the grid (no swing) in a fresh session at 134bpm, usually the timing is fine. The 16th notes sound even and the rest = a drum roll that sounds even.

So I think I'm fine. I start building my song. I add my synths, lalalala, timing sounds fine. In a day or two I have a nice 10 minute song going. Because of the "bug" where some uncleared controller data makes the sessions really really long, there's hundreds of extra measures in my track, but oh well.

Oh! That reminds me of other things I've tried:

- Make sure the controller data is reasonably thin.
- Reduce the number of plug-ins on any audio tracks or AUX tracks to like, 3. This should be fine. I have a G4 400MHz
- Make sure the application is running from the boot drive while the session files and any audio tracks (if any, yet) are on other IDE tracks (on 7200rpm drives, etc.etc.)
- Make two tracks in a blank session of the same part and hit play. Sure enough, they sound "flangy," good enough timing to be considered precise. They are for all practical purposes identical. They sound the same. They sound fine. This is easy to hear with a kick drum on 1/4 notes at 134bpm. They sound fine.

So back in my session with the masterpiece I started two days ago that has all the MIDI tracks and all my beautiful parts of my latest choon, I hit play and solo that same drum "roll." Funky. It's all wiggedy. The 16th notes that were stable in my test are now all crap. Crap, crap, crap. I could make an audio recording and zoon in to the grid. Here's what I'd see:

|MIDIEVENT...|MIDIEVENT...|MIDIEVENT...|MIDIEVENT. ..
.|AUDIEVENT..|AUDIEVENT..|AUDIEVENT....|AUDIEVENT. ..

They don't line up, and it's not a question of latency. It's not regular. My perfect MIDI has been funktified, and not in a groovy way. I'm back to square one. I cannot determine whether for some reason PTLE is sending out perfect MIDI timing and it's getting messed up later in the chain somehow, or if PT really has crappy MIDI timing when you've got +16tracks of MIDI, many with some (not a lot) of controller data (cc71, cc74, you know -- synth cutoff and freq stuff).

So I go back to my test. Rock solid in a fresh session. Back to my big sloppy masterpiece.

- Look at my MIDI event list. Delete anything that's not essential (notes, two or three sets of thinned cc data streams).
- Set to Grid mode
- Solo channels

...This is the exact topic I came to the DUC to discuss today, so even if this is slightly different than the original topic, I'm happy to see people discussing it. Some of you seem to not have the problem... what's my problem, I wonder?

I hope I have left room for answers.................................?

Please help if you have any ideas for me. If you like, I can send you a session with the audio files so you can see what I mean. You could re-record the same MIDI and show me your solid timing. It sounds like a stupid test, but this is the point I've reached with it. I need to depend on this to work, and it's simply not. [img]images/icons/frown.gif[/img]

[KennyB]

I know exactly what you mean.

Is it all going down ONE MIDI cable at the same time? If you have lots of things all hitting on the same beat then you may be getting the effect I'm describing above - the drunk drummer effect (very descriptive).

I have a track where the drum programming sounds fine - nicely "human" - but try putting a loop with it and you really hear the timing variations...........

It could be OMS, I'll try an experiment with Logic to see if that performs better.
Although, I do have a feeling that PT is more concerned with accurate audio output than accurate MIDI output. The more audio tracks - the worse the MIDI timing. IMVHO.

Back in the atari/cubase days I would shift some MIDI notes ahead of the beat and add an appropriate amount of silence at the front of the corresponding samples to try and get better timing.

The response of some sound modules to MIDI input can be VERY sluggish too. Particularly if you are running them multitimbrally.

[mobmusic]

Originally posted by KennyB:
I know exactly what you mean.

Is it all going down ONE MIDI cable at the same time?

I'll try an experiment with Logic to see if that performs better. Although, I do have a feeling that PT is more concerned with accurate audio output than accurate MIDI output.

<font size="2" face="Verdana, Arial">No, it's not all going down one MIDI cable -- I have a Micro Express, using 2 ins and 3 outs. But again... I have a list of things I forgot to tell you I've tried...

- I've soloed the MIDI track (this should address the multitibral issue you bring up and the "all down one cable" issue)
- Turned off MIDI clock send (unchecked it)
- Turned off the input devices (unchecked them)
- Tried OMS' IAC bus -- this doesn't rely on cables, obviously....

Let me know if Logic is better. [img]images/icons/smile.gif[/img]

I can verify that adding audio tracks seems to increase the severity of the problem. So does incresasing the HW buffer size. Even at 128 though, there are problems (although less significant).

This isn't about latency strickly -- I know how to adjust the tracks to compensate for latency (the best way is not by editing the MIDI note attacks, of course -- it's by changing the MIDI offset. Sometimes this number approaches -4800 but it fixes the latency issue... it does not make the beat "regular," just "as drunk" and not "always really late").

Other ideas? Other people with this problem? Will PTLE6 fix this in X for me?

Should I give up and simply commit to my MIDI as it is and then go through the task of replacing all the MIDI notes with individually pasted audio samples of each hit (this is what I've resorted to in the past)? The biggest drawbacks to this approach are that:

- changes become more difficult
- I cannot export MIDI files of my song to send to colleagues and remix artists
- I CANNOT CHANGE TEMPO LATER!!!!

Sorry for the shout, but it's a pretty big drawback for me creatively and technically -- sometimes the client just wants it a big slower or (usually) faster.

* * *

It's been a couple hours since I posted and no one has replied so I'm adding to my post. I have done some more research and there seem to be three (or more) general discussions going on, mostly in the MIDI forum.

1. The Swing feature is [insert expletive here] underdeveloped.
2. Timing slop in PT v [insert sequencerapplication here].
3. MIDI is ancient [insert mLAN or CoreMIDI here] will save us... someday.

There is a subtopic regarding USB MIDI timing slop.

I guess this thread is maybe more about topic number 1, which doesn't interest me, so I'll leave it now. If you're interested in topic 3, whatever. Rant or rave as you will.

If you're interested in topic number 3, here are some links to threads you might be interested in. One person posted a buncha MIDI timing tips, which I will go read now.

<http://www.hinton.demon.co.uk/mac/macmidi.html>

Anyone noticing MIDI slop with 5.1?
http://duc.digidesign.com/cgi-bin/ub...;f=37;t=000144
"I'm noticing that a simple Kick, Snare & Hat track are all over the place from time to time."

MIDI timing inconsistency?
http://duc.digidesign.com/cgi-bin/ub...;f=37;t=000122
"When checking out the MIDI sequencing for the first time I was unable to even get 16th note quantized hihats to play back evenly at 120 bpm."

Jittery, Glitchy Midi Fix?
http://duc.digidesign.com/cgi-bin/ub...;f=37;t=000028

Drums/click going off time?
http://duc.digidesign.com/cgi-bin/ub...;f=37;t=000820

midi is drifting...on G4 dual 500
http://duc.digidesign.com/cgi-bin/ub...;f=37;t=000093

001 midi timing
http://duc.digidesign.com/cgi-bin/ub...;f=37;t=000185

Pro Tools MIDI Timing - A possible solution?
http://duc.digidesign.com/cgi-bin/ub...;f=37;t=000160

HTH,

[J Blazin]

Thanx Burner, it seems to work great now!

[The Mighty Burner]

I think you miss my point - MIDI is a serial data link, therefore events transmitted over it CANNOT happen at the same point in time

This is not latency, its just the way serial data transmission works - its serial, things happen one after another. One note then another note

Oh, and show me the MIDI cable that REASON uses to communicate with its soft synths..................

<font size="2" face="Verdana, Arial">I don't know if I am misinterpreting your tone here, but let me just say that it sounds as if you are on the defensive, so if I've offended you in any way, I apologize.

However, I still don't understand how your point is relevant to the topic. Maybe what you mean to say is that two bits cannot be transmitted at the exact same time? Multiple midi events can absolutely happen at the same point in time, because it's a concept that is dependent on how midi devices interpret data, not how the data is encoded and transmitted. Yes, midi data is transmitted serially as strings of bits, but that has no bearing on latency or the timing between midi events (the topic being tackled here)...timing of midi events has nothing to do that. The only thing that is relevant is if you are connecting midi devices serially, you will inccur latency times which will increase with every device in your daisy chain. The latency in a midi data transmission between devices is about 3ms, so if you daisy chain three devices, you will have about 6ms latency in the data stream when it hits the last device in the chain. It has nothing to do with the timing of midi events, just the overall latency of the data stream. If the devices are mulit-timbral, you can have many midi events happening at the same time and they are not effected by how the data is encoded, transmitted, and decoded (unless of course your data stream becomes corrupted by a extremely length cable or something).

As far as Reason...if you could visit my studio I could show you the midi cable running from my keyboard to my interface! I don't know why you would be resistant to the fact that Reason is an entirely MIDI based software tool. All the soft synths and samplers are triggered via midi data; the redrum and maxtrix devices are pattern-based midi sequencers; the edit/arrange window allows you to create full arrangements composed entirely of midi data...midi, midi, midi.

I don't want to get into a personal arguement here...I don't think that serves any purpose, especially for the topic and the original poster. J Blazin seems to be on track, so it's all good!

Peace,

[KennyB]

Burner.

OK, you may get delays between MIDI in and MIDI thru (is that what you mean by latency?) but it will be a constant delay, and so easily got around by advancing your sequencer tracks accordingly.

But......

Multiple midi events can absolutely happen at the same point in time, because it's a concept that is dependent on how midi devices interpret data, not how the data is encoded and transmitted. Yes, midi data is transmitted serially as strings of bits, but that has no bearing on latency or the timing between midi events (the topic being tackled here)...timing

<font size="2" face="Verdana, Arial">This is just plain wrong. Sorry, but I don't know how else to put it.
Your sequencer may say all the notes occur at the same moment but the module at the other end of the MIDI cable gets them one after another.
Delays due to this are totally dependant on the amount of data being transmitted and so appear to be random - which is why it is so noticable, especially on drum programming.

And finally, while Reason does accept data from OMS (your keyboard is connected to a MIDI interface that communicates with OMS), it does not use MIDI internally.
MIDI is a hardware interface (RS232 current loop running at 31.25k BAUD, 1 start bit ,8 data bits, 1 stop bit) and a communication protocol.
What the sequencer in Reason displays is not MIDI data, its just a representation of the note, its velocity and duration.

Sorry if this comes across as defensive, nothing could be further from the truth.

[The Mighty Burner]

Originally posted by KennyB:

OK, you may get delays between MIDI in and MIDI thru (is that what you mean by latency?) but it will be a constant delay, and so easily got around by advancing your sequencer tracks accordingly.

<font size="2" face="Verdana, Arial">Nope. I'm talking about midi data transmission between any two midi devices...it takes about 3ms, which in itself is not significant, but it does add up if you connect devices in a "daisy chain" fashion, IOWs, serially. And yes, you can set a global offset to compensate for this.

This is just plain wrong. Sorry, but I don't know how else to put it.
Your sequencer may say all the notes occur at the same moment but the module at the other end of the MIDI cable gets them one after another.
Delays due to this are totally dependant on the amount of data being transmitted and so appear to be random - which is why it is so noticable, especially on drum programming.

<font size="2" face="Verdana, Arial">This may technically be true, but you are talking about the bits and the MIDI word commands that are received sequentially by the sound module, not how that data is converted into actual sound. I may look into it some more, but the bottom line is I have not experienced this. I can play 16 channels of midi data into my multi-timbral sampler, and it performs them all, totally in time, so I still don't understand. It seems to me that ALL digital data is written "sequentially" in data blocks, so I still don't see the relevance. Please elaborate, as I would like to understand better, but I just don't get it...it seems to make sense on the surface from a technical perspective, but I don't hear it. And if this were true, then it seems to me that no one would be able to construct perfectly timed, multi-channel MIDI sequences with any success.

And finally, while Reason does accept data from OMS (your keyboard is connected to a MIDI interface that communicates with OMS), it does not use MIDI internally.
MIDI is a hardware interface (RS232 current loop running at 31.25k BAUD, 1 start bit ,8 data bits, 1 stop bit) and a communication protocol.
What the sequencer in Reason displays is not MIDI data, its just a representation of the note, its velocity and duration.

<font size="2" face="Verdana, Arial">Again...I don't understand. Ummm...isn't MIDI a representation of note, velocity, and duration information? MIDI is a data protocol standard that enables different manufacturer's hardware to communicate, but it's not exclusive to hardware...there are countless software programs which use the MIDI protocol: Pro Tools, Cubase, Logic, Battery, Kontakt...where are you getting this info? It just doesn't make sense to me....what other type of data protocol could it be using? Are you telling me that when you transmit MIDI data via a controller into Reason, the program is converting it to another data format that "looks" like MIDI, but isn't? What about the discrete MIDI channels that you can output from Reason via rewire? what about MIDI information which is shared inter application with Reason via the IAC bus? I'm sorry, but not only does it seem illogical, but it borders on absurd. I guess I can't definitively say it isn't true, but it seems highly unlikely that Reason uses some other data protocol, and that it's sequencing and editing functions are manipulating anything other than MIDI data.

I definitely don't claim to be any kind of MIDI expert, but I am pretty well versed in basic software technologies and digital data transmission, and I think I have pretty good common sense and assesment skills. Your comments, when weighed against my experience and knowledge, just don't compute. However, I am always interested in learning more, so I would love to hear more about this, but maybe another thread would be more appropriate since this is getting a bit OT....

Of course, if any one else cares to chime in, please do.

Holla@ya!

[silverglove]

Here's how I fixed the timing problems in PT.....
MPC 4000

[accession]

Hi The Mighty Burner,

You wrote:

Multiple midi events can absolutely happen at the same point in time, because it's a concept that is dependent on how midi devices interpret data, not how the data is encoded and transmitted.

<font size="2" face="Verdana, Arial">This is not correct, I'm afraid to say.

Every complete MIDI message takes just under a millisecond to make its way serially (one bit after another) down the MIDI cable.

There'll be a MIDI message for one note, and a MIDI message for another note, however there's certainly no type of MIDI message that encompasses both notes should they need to be played together.

Nor are the MIDI events sent ahead of time, then buffered inside the receiving device with a specific time to sound them, in order to allow simultaneous notes to sound simultaneously.

(Although, it's true that digital synths and samplers will incur some latency during the sound generation process and the D/A conversion on its outputs).

If two notes are scheduled in the sequencer to play together, each note message is sent one after the other, meaning they'll actually play around 1ms apart.

That's a fact.

In fact, the MIDI protocol is almost 50% slower than a 56k modem.

So then, if the first beat of a measure in your MIDI sequencer contains:

1 note kick
1 note closed hat
1 note crash
1 note bassline note
2 note lead synth
3 notes of some other synth
5 note pad
1 note sound effect
1 note vocal snippet

...for a total of 16 notes, or just over 15ms...

...and then you decide to reinforce the kick drum with another similar but different kick layered over the top, the second kick drum will be triggered late by over 15ms.

Then say, on the next beat of the measure, only half the instruments might be triggered, and so this time the second kick might fall, say, 7ms late.

As a result, the two kick drums, in their layered state, will sound different on every occurrence due to the varying relationship in timing and therefore phase.

Although you may not hear it as timing slop (a few milliseconds is next to nothing from a 'groove' perspective), and it seems Pro Tools has its own major MIDI timing issues once the CPU is loaded up with audio plug-ins, however, let it be known that similar sounds, once layered together as MIDI notes, such as kicks and kicks, snares and snares, hats and hats, will reveal random phasing with each other when triggered via the MIDI protocol.

Layering in audio does not cause this problem.

The only workaround: deactivate plug-ins, solo then print MIDI instruments to audio tracks, and re-enable plug-ins.

With any luck, PT 6.0 and Digi's own MIDI interface (with 'time stamping') will correct the 'slop' inherent in Pro Tools MIDI, leaving just the 1 message-per-ms limitation to contend with.

Phil