Category Archives: Article

Understanding MIDI Track Offsets in Pro Tools

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:

  1. whenever you want to re-check the current running wrong avid placement of the recorded MIDI track, record audio along with it.
  2. 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).
  3. manually offset the MIDI track after recording (might be something like +1791 samples).
  4. mark the MIDI regions that you manually offset with colour or region name to ensure they were moved.
  5. 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).
  6. check this often, or you may not be recording where you think you are.
  7. 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.
  8. 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.

Avid ProTools – Shit That Still Isn’t Working Right And Needs Fixing



This post is where I vent about ProTools, the world’s benchmark DAW with an ego to match – it is a phenomenal editing platform, but in its glorification there are some unaddressed problems remaining.  Having shoveled money into the application for decades, it’s somewhat cathartic to at least list these issues.  Last update: 160121-2150

  • CLIP FADES:  the actual math behind the fades is crude as though it hasn’t been revisited since 1996.  I’m well-tired of pleading with the curve settings to create a pleasing shape, which almost never satisfies at the quiet end – leading me to believe that the math is still 8- or 16-bit.  I almost always resort to some combination of clip fades and volume automation.
  • RANDOM ARRANGE WINDOW DARKENING:  zooming in/out can sometimes spontaneously create a darkening of the majority of the arrange window, which can also appear to be a selection of the entire range of tracks and edit window length.  This has been occurring on desktop and laptop for at least six years.

Sample Conversion Software and Exported Formats

PLEASE NOTE: this is my own independent research, so please verify with trusted sources. Please send any corrections/additions to my contact email. Last update: 150414-1100.

In the pursuit of finding good tools for the creation of sample packs across multiple platforms that are both functional, up-to-date and reliable, one finds challenges.

Chicken Systems

Even the thought of this company makes me give up on this post.

Digital Audio Interfaces, Drivers and Compatibility with OSX 10.9 Mavericks

PLEASE NOTE: this is my own independent research, so please verify with trusted sources. Please send any corrections/additions to my contact email. Last update: 150215-1100.

I’ve started a list of current digital audio interface drivers and their currently supported Apple operating systems, including OSX Mavericks.

Digital Audio Interfaces – Currently-Supported

  • Avid third generation Mbox Family products (Mbox Mini, Mbox, Mbox Pro):  Mac driver 1.1.2 adds Mountain Lion support; 1.2.0 added support for Pro Tools 10.3 – Pro Tools 11; 1.2.2 was the last driver version before 10.9 support; 1.3 specifies Mac OS X 10.9 Mavericks support onlyNote: Mac OS X 10.9.1 Mavericks is NOT approved at this time.  Requires Pro Tools 11.0.3 or higher.  The meaning of the driver version 1.3 declaration seems to suggest that the driver ONLY works for OSX 10.9.0 (no other previous OSX) and NOT 10.9.1 (ie. the usual “new OS versions not approved until tested”); and that versions of Pro Tools before 11.0.3 will not be compatible with this driver.  All of this suggests sticking with 1.2.2 until you’re ready to use Pro Tools 11.0.3.  It also suggests that Mbox users will not be allowed to enjoy Mavericks and Pro Tools 10 simultaneously.  Users may bear some software upgrade expense, generally, moving from Mountain Lion to Mavericks, and a forced upgrade of Pro Tools will be a welcome addition to that outlay.  Pro Tools users not ready for Pro Tools 11 (plug-in upgrades, etc) will want to wait on the Mavericks upgrade.  Finally, users of older Digidesign-branded hardware may experience some frustration with abandoned drivers, not updated to Mavericks.  It all points to spending more money on both hardware and software, or sticking with OSX 10.6-10.8, Pro Tools 9 and older hardware.
  • Avid Pro Tools 11 Approved Audio Interfaces and Peripherals
  • Apogee Electronics – Symphony I/O – [√] Support page features specific driver update for OSX 10.9 Mavericks.
  • Universal Audio – Apollo A16 – I’m seeing 10.8 support but not 10.9
  • Universal Audio – Apollo Twin is fully qualified with Mac OS X 10.9 Mavericks.
  • Universal Audio – Preliminary testing with UAD v7.4.0 (and v7.4.1 Public Beta for Mac) indicates no significant issues with current UAD-2 and Apollo products under Mavericks, however [these issues] have been identified. Mavericks will be fully qualified in a future release.
  • Universal Audio – UAD Product Compatibility with Apple Mac Computers
  • RME – FireWire Interfaces – Mac OS X Intel driver for Fireface 400, 800, UCX, UFX, version 3.19. Compatible to OS 10.6 and up, 32/64 bit. This driver requires firmware 1.70 (FF 400) and 2.77 (FF 800) or higher.  Updated November 4, 2013.
  • MOTU universal audio installer – [√] all audio products including legacy products supported on Mac OS X 10.6, 10.7, 10.8 and 10.9
  • Echo Audio: visit their support page for Mac OSX

Digital Audio Interfaces – Legacy

  • Digidesign MBox2 Pro – driver build 78630 claims to cover OSX 10.9 Mavericks and supports ProTools 10.3.3 – ProTools 11.  Note:  the following dubious information is listed on the Avid site:  “Support for Mac OS X 10.9 (Mavericks) – note that uninstalling requires manually deleting files“.  Here is the list of files to manually uninstall.  The files installed by my own attempt were different than listed.  I’ve personally been installing a bunch of new things in 10.9.1 and have had some crashes which seem related to this driver.