here we explore the methods of testing your system for delay compensation / latency in MIDI Track Offsets. Global vs Individual tracks. How to build a working system you can rely on.
pg 657 and 941 in the manual
i should note that i AM using the video engine and i AM running video through all of this at Full Quality. it’s understandable if running video could muck up MIDI timing. the goal is, though, to compose to 1080P picture, isn’t it?
what i do: i record the instr trk and the audio track at the same time, i can see the audio where i wanted it, i can see the midi fkd up where avid couldn’t figure out where it goes. i find the samples offset (+1791 samples push later… in current config at least), and then i put this 1791 value in global MIDI playback offset…. and then my wrong MIDI tracks are corrected with a playback offset. this is fine unless i want to do anything with the out of place MIDI. otherwise i need to move MIDI regions offset +1791 in the playlist. i could pop notes and cc within the region +1791, which would be the right thing to do, but would this grab everything? better to just take the whole region using a script. ………… so it’s actually adjusting MIDI notes to underlying audio recording, and checking that sample offset for what that number actually is – the MIDI is the culprit and the audio track is solid.
a working plan:
- whenever you want to re-check the current running wrong avid placement of the recorded MIDI track, record audio along with it.
- the audio will we correct (properly compensated) whereas the MIDI will be wrong – find the sample offset between the first mod of the audio, against the head of the MIDI note (remember to take into account that with sampled sources, there could be some ‘air’ preceding the sample).
- manually offset the MIDI track after recording (might be something like +1791 samples).
- mark the MIDI regions that you manually offset with colour or region name to ensure they were moved.
- using a MIDI track feeding an instrument track (normal working method), the current running wrong Avid placement needed to be offset by +1688 (in other words Avid overshoots less).
- check this often, or you may not be recording where you think you are.
- to make this EVEN MORE COMICAL, and to show the very low priority that the MIDI engine is in Pro Tools, find the offsets for more than a few notes – the results will vary from 1000-2000 samples. Again, the audio performance is recorded, and the MIDI is very sloppily recorded in comparison.
- the hunch is fulfilled, that it makes sense, whenever you don’t need MIDI, to record with a secondary system, performances that are recorded like any other incoming audio. Pro Tools is a DAW, not a MIDIW.
All of this means we’re back to Pro Tools LE in 2006 where you had to manually delay-compensate your recordings. Pro Tools needs to catch up with the other DAWs in this respect.
It gets worse: the audio did happen in real time, and it should be correct, but is it? The MIDI seems to deviate from the audio by up to 1000 samples (?!). In my 48k context, this is 21 fucking milliseconds. And this isn’t the poorly corrected delay compensation, this is the wobbliness of the MIDI notes against the audio, or the audio against the MIDI notes, or BOTH — or the display of the MIDI notes, or ALL THREE. If there were at least a common fuckup offset on the MIDI track, that you have to manually impose an offset on the region after every fucking recording, that would be one thing. But to not even be able to calculate the offset? To have to estimate an average value – fuck sakes. Is this the result of measuring a tick-timebase track against a sample-timebase track?
If you record the resulting MIDI playback back to audio (so at least you can compare waveform to waveform), and compare against the original record audio, you can see that indeed the wobbly MIDI capture is ‘baked in’ – the offset varies when comparing the original audio against the audio record of the post-playback MIDI track. That leads us to believe that the MIDI capture routine is casual.
[Record out the moving flam of the two records, to illustrate how sloppy it is – cymbals works great] For tight robotic techno genres, a discrepancy like this would be a disaster, but even for every other genre, this is on the order of mangling the feel of performances, where ever millisecond counts. The intended performance must be captured. With a MIDI record error of this scale ON EVERY MIDI PERFORMANCE THAT GOES INTO PRO TOOLS — this is the capture engine, NOT controller latency, not delay compensation — it means your notes aren’t being recorded with precision in the system.
Thankfully playback of MIDI notes seems bulletproof. An audio recording of MIDI seems to be tight mod-to-notehead consistently. But we do know that there is a discrepancy between what a player plays on the keyboard, what is being performed in real time by the Instr track out to audio, and what the captured MIDI placement looks like.
If this isn’t a convincing argument to stick with Logic for MIDI, I don’t know what is.
If anyone knows how to improve the accuracy and stability of MIDI capture into regions in Pro Tools, please get in touch with me.