MIDI timing issues in DP & maybe osx in general

[HCMarkus]

You can also just "Clear" and "Restore" plugins on master fader.

[James Steele]

I just got word from someone offline that I might have had this wrong. I need to investigate further.

[MIDI Life Crisis]

I just got word from someone offline that I might have had this wrong. I need to investigate further.

!

[stubbsonic]

Forgive me if I'm missing something, but if MOTU touts incredibly accurate (sub-millisecond) MIDI with their interfaces, and allows you to calibrate the timings to a fine degree, then 3 ms is substantial- because all errors in timing are cumulative.

If we add up various sources of latency and slop (including the meat-bag behind the keyboard), we'd want it to be a small and consistent number. Furthermore, if there is a correct way to set up buffers, compensation, offsets, etc., then DP should handle all that stuff appropriately.

Ideally, I'd like to calibrate all that stuff correctly and only have to do it once per interface.

[mwilloam]

Just want to jump back in and reiterate that the 3ms offset that's getting the most discussion is only one of many outcomes. Often I'm tracking at 128 or even 2048(without patch thru) and in those cases the offset can be greater than 20ms in one direction. While 3ms IS an issue for the higher tempo/rhythmic music I make, I imagine 20ms is a problem for most.

All this said, MOTU has already acknowledged this is a bug as of 9.1 and supposedly working on it. I just wanted to corroborate with others to rule out system specific issues i may have and to get some community QA.

[HCMarkus]

It is important to note that it took about 18-19 ms from key strike to key bottom with weighted key while generating velocity of 127 (meaning shortest time from strike to bottom). This puts things in perspective.

Key Depress (Bottom) - Buffer 128
MIDI Event ahead of Audio by about 1.5 ms.

Key Strike (First finger contact with key)- Buffer 128
MIDI Event behind Audio by about 17 ms.

I should also point out that external MIDI Output varies inversely to the above. If you record MIDI at one buffer, you get an inverse (offsetting) timing when outputting MIDI using the same buffer. This is not an issue for Virtual Instruments... Internal VI response (and audio playback) is essentially perfect, within about a sample if DP is properly calibrated, regardless of buffer size.

MOTU has responded to my tech link, and is investigating.

[mwilloam]

It is important to note that it took about 18-19 ms from key strike to key bottom with weighted key while generating velocity of 127 (meaning shortest time from strike to bottom). This puts things in perspective.

Key Depress (Bottom) - Buffer 128
MIDI Event ahead of Audio by about 1.5 ms.

Key Strike (First finger contact with key)- Buffer 128
MIDI Event behind Audio by about 17 ms.

I should also point out that external MIDI Output varies inversely to the above. If you record MIDI at one buffer, you get an inverse (offsetting) timing when outputting MIDI using the same buffer. This is not an issue for Virtual Instruments... Internal VI response (and audio playback) is essentially perfect, within about a sample if DP is properly calibrated, regardless of buffer size.

MOTU has responded to my tech link, and is investigating.

This is good detail as well thanks. Again, my original test which was simplest, was Roland td-30 recording MIDI(usb) and audio out direct to 1248(analog 1-2) with offset up to ~25ms early to late so ~50ms total across range. And while there will always be SOME offset between the MIDI and audio capture, it should be audio buffer independent.

[towerproductions]

Here’s something I recently learned that may or may not help: any plug ins (like mastering limiters, etc) on a master fader are not latency compensated and this will wreak havoc with timing when trying to record MIDI late in a project or if you like to work with a limiter etc on a master fader. A workaround is to temporarily assign the master fader to another output I believe.

I've heard this as well. Supposedly it's a bug with latency compensation. Another workflow is to use an aux track as a "master" with a virtual bus input and a hardware output and skip masters all together. Benefit also is you can apply mix inserts here and still pipe it to an audio track to realtime record if so desired. To the original tests, I had no master faders, just MIDI and mono audio.

I discovered this as well not long ago when I was trying to add some MIDI tracks to a project after it was in the project and in mixing stage . I ended up adding an aux track and moving my master fader EQs , compressors/limiter to there which kept all the settings the same since bypassing turning them off did not work with latency issues .

[HCMarkus]

Here’s something I recently learned that may or may not help: any plug ins (like mastering limiters, etc) on a master fader are not latency compensated and this will wreak havoc with timing when trying to record MIDI late in a project or if you like to work with a limiter etc on a master fader. A workaround is to temporarily assign the master fader to another output I believe.

I've heard this as well. Supposedly it's a bug with latency compensation. Another workflow is to use an aux track as a "master" with a virtual bus input and a hardware output and skip masters all together. Benefit also is you can apply mix inserts here and still pipe it to an audio track to realtime record if so desired. To the original tests, I had no master faders, just MIDI and mono audio.

I discovered this as well not long ago when I was trying to add some MIDI tracks to a project after it was in the project and in mixing stage . I ended up adding an aux track and moving my master fader EQs , compressors/limiter to there which kept all the settings the same since bypassing turning them off did not work with latency issues .

I just clear inserts then restore after recording stuff late in the project. Just to be safe, I'll save the mastering chain as a preset with the song name as its title.