MIDI Latency Compensation

[Prime Mover]

So, for a while now, I've suspected that DP8 was pushing my MIDI recordings ahead in time (to the left), from where I'm trying to play. I ran a test and boy was I right! Because my computer is a little slower, and I often am working on larger projects, I often keep the buffer at 512. I've learned to play with a slight latency, and my brain has just adjusted. But what I don't like is that DP tries to adjust the MIDI BACK to where it should be, so when I play it back, everything feels ahead of the beat.

So I finally ran a little test, I recorded the VI in real time to an stereo track, and then recorded it back again afterwords, and sure enough, there as a 30ms difference between the tracks! When I lowered the buffer, the discrepancy became less.

Here's a screenshot, the first audio track is what I heard while I was playing, the second is what I hear when I play back the MIDI afterwards:


Are there any settings to get DP to write the MIDI where I actually played it instead of forward? It's like it's trying to overcompensate.

[mwilloam]

I think this is the case of the default MIDI patch thru...

Got to Studio -> MIDI Patch Thru... and uncheck Sync Recorded MIDI to Patch Thru.

This setting is on by default in DP which I think is bad as it has ruined a few recordings I did without knowledge of the delay until I heard it. Basically it compensates for the buffer latency but I'm not sure I see a great use for it yet. Maybe someone else can chime in.

[Prime Mover]

I've run some tests and I notice absolutely no difference between this setting on/off. Not sure if it somehow got disabled my revision of DP8.

Here's what I did, I set the buffer to really high (1024), so I could really hear the difference. Then I recorded myself playing to a click and self-compensated so I thought that I was good and on the click. But when I played it back, it was far ahead, with the setting both on and off.

So currently I'm just turing the buffer down as low as I can (128), but on more complex projects, that's gonna be a problem.

[Phil O]

I've never investigated this setting (so I don't know exactly what is does), but have you looked at Fine Tune Audio I/O Timing in the Setup>Configure Audio System menu? It's not discussed in the User Manual. Look at the Getting Started Manual. Just a stab in the dark.

[Timeline]

I have a tune I recorded in 2011. I recorded 10 tunes back then but this one has an issue nobody can figure out. The song played fine up through DP8. As soon and I went to 9 it went out of sync yet all the MIDI and audio files were spot on as shown in the sequence editor. A different issue but sync related. To correct it I put 50000 samples into the IO timer and it sunk back up. Weird hugh !!

I wonder if this is a global setting because I will need to remember to remove that to use other tunes.

[Prime Mover]

I've never investigated this setting (so I don't know exactly what is does), but have you looked at Fine Tune Audio I/O Timing in the Setup>Configure Audio System menu? It's not discussed in the User Manual. Look at the Getting Started Manual. Just a stab in the dark.

Ugh, I was so hopeful this was going to help... read the manual, tried to test it out with all different kinds of settings, nothing seemed to do anything. Even when I set really large values (1000-2000+), I could not hear a discernible difference, and the same flamming between MIDI and recording still persisted. I even tried setting a VI to "run this instance in realtime", and turning off the Sync option, nothing seemed to have any effect. I suspect that I/O timing slides EVERYTHING over, and only helps if you're running to outboard gear.

UPDATE: Okay, so I was able to make some progress, but it doesn't make much sense. If I set the "Playback Offset" to TWICE the negative buffer (so "-1024" if my buffer is 512), it seemed to lock in more, but not exact, so there's a slight flamming and phasing, but WAY better than before, good enough for locking in with other instruments, anyway. Funny thing is, I've tried increments up until -1600 and I don't hear any difference, then -2000 is really off... so I give up on trying to understand this thing.

[Sean Kenny]

Sorry about the image not displaying properly click on this link to view full image in your browser. http://www.intonationalrescue.com/motui ... gissue.jpg

Strange one this one! (NB: see the markers window for exact positions) Recorded @ 88.2Khz / 120bpm / 2048 samples latency

I just did a test here using the qwerty keyboard to input MIDI and simultaneously bussed the output of the motu Bass instrument (Live) to the input of a record armed stereo track (See Channel strip).

In this instance I used;

1: the internal click bussed out through my converters in it's own discrete channel and recorded back in to DP (see green track)
2: an external click generated by an Alesis D4 and recorded back in to DP (see blue track)

MIDI delay compensation is none existent by the look of things. My timing is pretty good (isn't everybody's!!) first beat is early then the following 3 are fairly consistent in relative position to the down beat.

I have stripped silence and placed markers at the start of each soundbite/MIDI note.

There are 2 'fairly' consistent instances here in relation to the down beat.

1: the external click seems to be the most accurate. Not only is it the tightest to the downbeat but more importantly the consistency in it's tardiness from beat to beat is reassuring considering that it is internally created, externally generated and recorded back into the system. Margins of error: Beat 1 (0ms); Beat 2 (1.77ms); Beat 1 (0.99ms); Beat 1 (0.22ms)

2: excusing the first beat, the remaining 3 MIDI notes (allowing human error) are also fairly consistent in their tardiness to the downbeat, albeit not correctly delay compensated (THE MAIN PROBLEM expressed in the original post)

This confirms my suspicion that the internal click is not as accurate as an externally generated click, ironically. See the Green and Blue track marker positions relative to the downbeat

The most disconcerting issue is the inconsistency in timing between the MIDI note and the internally generated audio. See the red and purple tracks respectively and the gaps between marker positions at the start of each MIDI/audio note.

This is the real worry! If this were consistent then all you would have to do is calculate the MIDI delay and simply nudge the whole MIDI track forward accordingly.

Given the inaccuracy in internally generated live audio (see the Green internally generated click track) I'm inclined to trust the integrity of the external click and the actual MIDI, in the respect of the constancy of any timing offset in relation to the downbeat. (•••• that's a mouthful .. but you get my drift .. hopefully).

Any ideas on this would be appreciated.

Sorry about the image not displaying properly click on this link to view full image in your browser. http://www.intonationalrescue.com/motui ... gissue.jpg

[Prime Mover]

All very strange. I'm really bewildered that this hasn't been talked about more, all of us seem to be seeing some troublesome timing issues across multiple versions (I'm on DP8.07, but Timeline had issues in DP9), yet it doesn't seem to be a common complaint. You'd think with all the attention so many detailed things get here, rhythmic accuracy would be on the top of everyone's list.

[HCMarkus]

I've run some tests and I notice absolutely no difference between this setting on/off. Not sure if it somehow got disabled my revision of DP8.

Here's what I did, I set the buffer to really high (1024), so I could really hear the difference. Then I recorded myself playing to a click and self-compensated so I thought that I was good and on the click. But when I played it back, it was far ahead, with the setting both on and off.

So currently I'm just turing the buffer down as low as I can (128), but on more complex projects, that's gonna be a problem.

Looking at your screen shot and your request:

Are there any settings to get DP to write the MIDI where I actually played it instead of forward?

This is clearly the issue that the "Sync Recorded MID to Patch Thru" preference is designed to address. To do so, you want to ENABLE this setting in preferences; assuming it is functioning properly on your system (as it is on mine), DP will record the MIDI events at the time the VI actually sounds while your are recording. As such, the exact time when the MIDI data is recorded will vary depending on the buffer size you are using when the recording is made.

With this preference enabled, if the buffer is small, the MIDI data will be placed close to (but still slightly after) the time you struck the keys. If the buffer is large (or you are running a look-ahead limiter on the Master), you will see the MIDI data placed considerably later than when you struck the keys.

What you are seeing in your upper audio track (which appears to have been recording the VI-produced audio as you performed the part) is NOT the time you hit the keys; it reflects the buffer delay. The moment you actually struck the keys is reflected in the accompanying MIDI Track. The VI audio on the playback track lines up with the MIDI because on playback DP knows in advance the notes are going to be triggered at a specific time and can fire them off at the exact moment the MIDI data hits.

Enabling Sync Recorded MIDI to Patch Thru will cause DP to place the MIDI data so it lines up with the upper audio track so, on playback, you will hear the VI sound at the same moment it sounded when you were recording the part.

Sync Recorded MIDI to Patch Thru is preference I would like to see on the DP control Panel, as it is a function that is sometimes, but not always, desired. I like using it with small to moderate buffer size; it compensates for the tendency to push time when a VI sounds with a slight delay.

[daniel.sneed]

Thanks for bringing your light on this subject, Markus.
AFAIU, you'll want to disable this feature while playing hardware synths. Its intended for tracking VIs only.

[HCMarkus]

AFAIU, you'll want to disable this feature while playing hardware synths. Its intended for tracking VIs only.

True dat.

A good reason to make this preference prominently available.

[Prime Mover]

Thanks for the description, but unfortunately it's only making me madder, because it just doesn't work like that for me, and it's exactly what i was hoping for

Strangely, DP has had some other time-based quirks on my system. Often the beat-syncing MAS plugins don't work (like MOTUs delay plugin), they just pick an arbitrary time, no matter what the tempo of the song is. This was present in DP7 for me as well. So I wonder if there is a clock problem somewhere in my system. Strangely, AU/VST plugins work fine though.

[terrybritton]

There are three other things to consider that have worked for me:

1) Make sure your clock is set to the correct time.

2) Tap with your toes rather than your entire foot in case it has been shaking things.

3) You have to hold your jaw set just right. It is in the manual how to do this. (pp. 3,867-3,880)

Terry

[HCMarkus]

Thanks for the description, but unfortunately it's only making me madder, because it just doesn't work like that for me, and it's exactly what i was hoping for

Strangely, DP has had some other time-based quirks on my system. Often the beat-syncing MAS plugins don't work (like MOTUs delay plugin), they just pick an arbitrary time, no matter what the tempo of the song is. This was present in DP7 for me as well. So I wonder if there is a clock problem somewhere in my system. Strangely, AU/VST plugins work fine though.

That's frustrating. Time to reinstall DP? Perhaps a call to MOTU...

[Prime Mover]

Terry, this is obviously not a case of my rushing, and even if I was, the fact is that the MIDI is ahead of the recording. It doesn't matter if I play to a click or not, the MIDI is always ahead of where the audio was when it was initially recorded.