MIDI timing issues in DP & maybe osx in general

[mwilloam]

Something I've witnessed since 9.13. Different audio buffer settings are causing varying offsets in MIDI timing, at least relative to performance. Here's an example of a test:

Macbook Pro 15 mid 2015
1248 over USB - latest drivers/firmware
Fastlane over USB - latest MIDI drivers
DP 9.52 76360

I had an sm58 right against the key on a Roland A33. So even if there is inherent latency in the Roland triggering that should be consistent across audio buffer changes.

2048 buffer: MIDI is ~20ms early relative to audio
1024 buffer: MIDI is ~3ms early relative to audio
32 buffer: MIDI is ~20ms LATE relative to audio

**consistent with MIDI patch through on/off and also Sync Recorded MIDI to patch through on/off.

This came up as I kept hearing MIDI recordings out of time. Noticed first by recording v-drum MIDI and audio together and seeing shift with buffer change.

Can anyone else confirm they are seeing this? If so, mind testing in another app as maybe it is a core audio/MIDI issue.

[HCMarkus]

Good idea, having the mic pick up the sound of the keyboard strike!

A few weeks back, I did some testing on my Mac Pro (see my sig below for specs)... DP's audio recording and playback timing are very solid. VI playback from MIDI is similarly solid, but MIDI output to external sound modules is a different story. Note that I was testing MIDI playback, not recording.

From my prior post:

Audio is running within 20 samples without fine tuning. Fine tuned to perfection for all audio by setting record offset of 20 samples and playback offset of 0. This is at a DP buffer of 128. Internal timing is maintained at buffer 1024.

Not sure if I am recreating the OP's test, but I can record (thru my 828es interface in digital domain via AVB Mixer) with consistent placement of audio within less than one sample. Also tested using a VI (BFD snare side stick sample) routed thru 828es and we are within 1 sample at buffer 128 and 1024.

Using an external instrument (Yamaha S90ES - acoustic piano sample) at Buffer 128, I get about a 7-8 millisecond delay from MIDI note transmission from DP; this is likely due to combined synth and MIDI response times, very respectable for MIDI. Interestingly (and this is something I noted and posted about here at MOTUNation several years back), the same test with Buffer 1024 results in about 28 ms delay. So the timing relationship between Audio and MIDI output from DP varies depending on DP Buffer size.

EDIT: I just sent a link to this thread to MOTU.

[mwilloam]

Cool thanks for confirming. FYI I've been in contact with tech support as well. This was good to validate across systems and rule out any user test error. Hopefully fixed soon...

Just to confirm for others reading, this is not an issue with MIDI to VI playback. That's fine, I think within 1sample. This is with MIDI input capture via recording.

[MIDI Life Crisis]

3ms is a problem? Lol

[mwilloam]

3ms is a problem? Lol

Yes. But I think you're missing the point. It's variability that's the issue and, your buffer size is going to change at times. Are you going to want to test offset each time? Plus, MIDI Time Stamping has been built in to core MIDI and was part of MOTU's interfaces back to os9. It's sub millisecond in its accuracy.

[HCMarkus]

Sync Recorded MIDI to patch through on/off should make a difference; MIDI notes should be recorded later and later as the buffer gets bigger. I'm gonna run a test here and see what I get using the mic against the keyboard approach. Reporting back soon.

As for the delay... 3ms is not a worry. 20ms gets me concerned.

[MIDI Life Crisis]

I do get the point. I’m think of this as a practical matter, not a scientific one. 3ms seems like a non-issue to me. But yes, consistency is a concern, for sure.

[HCMarkus]

Test Keyboard: Yamaha S90ES connected via USB, Yamaha USB Driver Software
Other Software and Hardware as noted in my signature.

TEST A:
Mic a few inches from keyboard
Finger resting on key... Depress key as fast as possible.
First sound picked up by mic is key bottoming out on keybed.

Buffer 128
MIDI ahead of Audio by about 1.5 ms. Sync Recorded MIDI to patch through ON
MIDI ahead of Audio by about 4 ms. Sync Recorded MIDI to patch through OFF

Buffer 256
MIDI ahead of Audio by about 4 ms. Sync Recorded MIDI to patch through ON
MIDI ahead of Audio by about 7 ms. Sync Recorded MIDI to patch through OFF

Buffer 1024
MIDI ahead of Audio by about 22 ms. Sync Recorded MIDI to patch through ON
MIDI ahead of Audio by about 25 ms. Sync Recorded MIDI to patch through OFF

TEST B
Mic a few inches from keyboard
Strike key as fast as possible
First sound picked up by mic is finger striking key

Buffer 128
Audio ahead of MIDI by about 17 ms. Sync Recorded MIDI to patch through ON
Audio ahead of MIDI by about 15 ms. Sync Recorded MIDI to patch through OFF

Buffer 256
Audio ahead of MIDI by about 15 ms. Sync Recorded MIDI to patch through ON
Audio ahead of MIDI by about 11 ms. Sync Recorded MIDI to patch through OFF

Buffer 1024
MIDI ahead of Audio by about 3 ms. Sync Recorded MIDI to patch through ON
MIDI ahead of Audio by about 6 ms. Sync Recorded MIDI to patch through OFF

ANALYSIS/CONCLUSIONS
Since this tests rely on me (a person) depressing or striking a key, there was a degree of variability in my results. However, after running each test multiple times, I feel confident that the measured results can be used to extract fairly reliable conclusions.

1. On my system (which does not use a MOTU MIDI Interface) the Sync Recorded MIDI to Patch Thru preference simply places recorded MIDI events about 3 ms. earlier in time, regardless of DP's buffer size. That's an eye/ear-opener for me.

2. Using my weighted keyboard, the time from striking a key and triggering a MIDI event (TEST B) is about 18-19 ms. longer than the time from when the key bottoms out (TEST A). I was consistently able to generate a MIDI Velocity of 127 using either method.

3. As first reported by MWilloam, DP's placement of MIDI events relative to audio varies depending on buffer size. The time difference from buffer 128 to buffer 1024 is approximately 20 ms. My results support MWilloam's findings.

Whether any of this makes much difference in how we make music is a completely different question. There are many variables that are not within DP's control:

Envelopes
Sample start times vary from VI to VI
VI (buffer size) and External MIDI Module response times
Distance from speakers (about 1 ms/foot)
Experienced performers naturally compensate for delays in sound generation within their instrument.

Although I'd like to see DP place MIDI notes exactly where they are played, it gets us close enough that our own timing imperfections far outweigh DP's. Also, as I recently confirmed in another set of tests, DP is very accurate and consistent in delivering audio and VI output when the VI is triggered from pre-recorded MIDI events.

It would be interesting to perform these tests with a MOTU USB MIDI Interface. Not sure if my 828es (which I run via USB) would suffice. At this point, I have work to do, so I will leave that to others.

[HCMarkus]

I do get the point. I’m think of this as a practical matter, not a scientific one. 3ms seems like a non-issue to me. But yes, consistency is a concern, for sure.

I agree MLC... if the variability does not make a practical difference, why worry?

After running the tests above, the fact that the time it took me to strike vs bottom out a key was 18-19 ms. definitely put things in perspective.

Regardless, it will be interesting to see if MOTU has anything to say about all of this. I have pointed them to this thread.

[MIDI Life Crisis]

And frankly, listen to ANY live ensemble performance or recording, regardless of the abilities of the performers, and you will hear (if you can hear that well) that on almost every single note, players are never in "perfect" sync. I can see that being and issue for some people. We call those people musicologists: people who can read music, but can't hear it.

I'm joking, but not all that much... If 3ms was going to bother me that much, then I'd get a job working a jackhammer. They remain in perfect sync.

[HCMarkus]

Mr. Jackhammerer looks like he is making a last-ditch effort to dig his way clear of the looming apocalypse... note the mushroom cloud just above the horizon in the photo's lower left corner.

He might be a tad late, maybe more than 20 ms.

[MIDI Life Crisis]

That’s no cloud but an actual 300’ tall mushroom, or something with a mushroom head... lol

[James Steele]

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.

[MIDI Life Crisis]

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.

Interesting, indeed!

[mwilloam]

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.