MIDI recording late

[bayswater]

On more shot at this. To get clearer results, I

1) set up a MIDI track in Logic with quantized quarter notes.
2) slaved DP transport to Logic
3) connected DP and Logic via IAC

Both Logic and DP had tempo at 120 BPM

I did this so I don't have to worry about vague results from imprecise playing. With that I recorded the Logic MIDI output in DP under various conditions.

Here is what I found:

- With nothing in DP but one MIDI track, the MIDI notes were recorded where they would be expected. So a note played at 1/1/0 in Logic is recorded at 1/1/0 in DP, i.e. within 1 tick. Looking at the timing of the recorded notes at the sample level, there was a delay of between 30 and 60 samples regardless of the DP buffer size. I attribute this to the time it takes to send the MIDI info via IAC. It amounts to about about 1 msec. So far, all is good.

Adding VIs to the DP project but not routing any MIDI to them does not increase the delay beyond the 30 to 60 samples at any buffer size from 16 to 1024.

Routing the MIDI track to a VI makes a big difference with larger buffers. I used TruePiano, and the F273 Piano patch from MachFive hosted in Falcon and a couple of other VIs. The delay was not affected by the particular VI used.

With MIDI routed to the VI here's what I found.

Buffer Size. Delay in Samples

16 189
32 254
64 368
128 584
256 1036
512 1933
1024 3705

From this and the previous tests its pretty obvious that DP is not compensating the buffer when MIDI is routing to a VI. At a buffer of 16 samples, considering the general delay inherent in the method I've used, DP is adding about 3 msec delay with a buffer size of 16 when a VI is used, but 83 msec when the buffer is at 1024.

Unlike previous suggestions, It does not matter if a VI is merely present if the MIDI track is not routed to it, and buffer size does make a difference, and unlike other suggestions, 1024 is not the optimal buffer size, at least not for MIDI.

I don't have enough different Macs to see whether this is depends on hardware, but from what I've seen, I have doubts. It just looks like software error in MIDI timing.

[smashprod]

Yes, you have delineated the exact problem. And it IS hardware dependent; neither M1 Macs nor AMD Ryzen PCs exhibit the problem. What is unknown is how many of the Intel Macs exhibit the problem.

And for film composers like me, 1024 is indeed the optimum buffer size for MIDI because we run all our VIs on slave machines via VEPro 7, so large hardware buffers do not cause any latency, only the buffer size in the VEPro plug in. Running a large setup with the VEPro plugs set to a low buffer is manageable, running the overall hardware buffer in DP at 128 is impossible, even on the fastest 12 core Westmere machines with everything on SSDs.


Sent from my iPad using Tapatalk

[smashprod]

If any of you are up for testing this on your Apple CPU (so we could know which ones don't have the bug), here's the method:
1) Set hardware buffer to 1048 or higher;
2) Turn on IAC in AudioMIDI Setup;
3) Create a MIDI track with a VI (any VI);
4) Enter a series of MIDI notes using step-entry and confirm that the events are exactly on the beat;
5) Use IAC to record from the output of that MIDI track to a new MIDI track in real time;
6) Check to see if MIDI track #2 is in sync with MIDI track #1.
If so, you've got a winning CPU, and please let us know!!

[dewdman42]

Chiming in to hopefully save others continued frustration and time. Accurate MIDI record timing has been broken since DP 9.1. MOTU tech confirmed back then and more recently mentioned there would be a fix in 11.03. I'm still using 9.52 and haven't got around to confirming myself but will soon. The bug was simply, changing the audio buffer would offset recorded note on events, late or early. And this wasn't a millisecond or two, you'd get upwards of a 40ms swing going from a buffer of 32 to 2048. The former causing notes to be ~20ms late and the latter causing the note to actually be placed ~20ms EARLIER than when the event occurred. You can see a prior discussion here:
viewtopic.php?f=1&t=65447&start=15#top

Hopefully that resolves some head scratching. I was amazed more people didn't mention observing this after 9.1.

This sounds like the culprit to me. I am very skeptical that this problem is directly related to the CPU. There could easily be a timing offset bug that is somehow related to Plugin Delay Compensation...since this appears to only happen when a VI is involved. I'm extremely distressed to hear that MOTU is writing off the Xeon. many of us are still using Xeon's and will be for a few more years. I would not have upgraded to DP11 if I had known about any kind of lack of support for the Xeon. I think that's a cop out though, there is nothing about the Xeon that should cause something like this to happen, DIRECTLY. perhaps indirectly in some way, but it comes down to a calculation error which MOTU should be able to hunt down and fix IMHO.

I will try to run some tests of my own this evening.

[dewdman42]

Nobody has really mentioned so far in these tests either what kind of MIDI interface they are using. If MOTU or not(with MTS).

USB MIDI drivers probably timestamp in software and who knows what is happening there...but if this bug has been around since 9.x...then its not related to the CPU directly...though its certainly possible Apple has introduced something into class compliant core audio usb MIDI drivers that might be broken with Xeon.

But since this only happens when there is a VI connected, I don't think that's it. its almost certainly a calculation error in DP somewhere.

[dewdman42]

also I question about the use of IAC to track down this problem. When MIDI is routed over IAC and back into DP, it would be normal to expect that the MIDI would go out and back in during a later process block buffer and would be late.

Its also safe to assume that DP is making some assumptions that since you are hearing audio delayed from buffer latency...that the MIDI should be sent out to IAC late also...which is why it loops around and records late again... That would not be a bug!

The only way I can think of to properly test MIDI track recording offset would be to setup a microphone next to your keyboard so that you can record the sound of your finger hitting the bottom of the keybed as well as the sound of the VI coming out of your speakers! if you can use two mics to isolate the keyboard click from the VI sound even better... and record that to an audio track at the same time as you are recording the MIDI to a MIDI track..(with a VI involved).

But even that test may not give results that should be considered a bug per say... depends on what MOTU is attempting to do. if you have latency while recording through a VI, then DP may be assuming that you are listening to a delayed instrument (due to latency)...and the human tendency is to play ahead of the beat in order to compensate for a latent instrument. We move our fingers early, so that we hear it on time. In such a case, the expected behavior of DP would possible be to offset the recorded notes to the MIDI track later in order to line up with when you actually hear them. That is how LogicPro works I can vouch for that after I ran through my own OCD head trip over WTF is happening with MIDI record offset there. That would not really be a bug per say.. But anyway the point is, with the microphone test, you would detect this without involving IAC which could bring its own timing problems not to mention an additional complexity related to the PLAYBACK timing....and what we are dealing needing to test here is the record offset timing of MIDI tracks.

[dewdman42]

and one more thing about the large buffer setting. Generally speaking, DAW's always use a very large buffer setting for all non-record-enabled tracks. always regardless of the setting you set in preferences. The setting we set in preferences generally only affects the currently record-enabled tracks.

So what I'm meaning to say is that generally speaking, what is the advantage of running a large buffer setting while you are trying to record MIDI tracks?

I also do not know the internals of DP as to whether they always use a large buffer for non-record-enabled tracks. I know that for LogicPro, that is the case. I know that for Vepro plugin, it imposes an even bigger buffer when its not record enabled, in the form of extra plugin latency, etc. The DAW's do this kind of stuff behind the scenes.

So generally the buffer size preference should only be affecting the track you're trying to record to. It would drive me mad to try to record to a MIDI track with the buffer setting at 1024, that is just way too much latency and I would never be able to trust the timing of whatever I played on a MIDI keyboard. And I question the usefulness of doing so unless the particular VI I am trying to record happens to be a very CPU hungry VI that needs a bigger buffer to avoid drop outs while recording that track. The rest of the tracks that are not record enabled, SHOULD be unaffected by the buffer setting.

So anyway, I will run some tests tonight...but part of me thinks this so called "bug" being discussed may not actually be a bug, but rather intended behavior.....but its just that with a large buffer setting...the latency messes with your head while recording, as simple as that. I've seen these same kinds of discussions on the LogicPro forum in the past for years. But if there actually *IS* some kind of bug that has been introduced we should try to track it down, because I for one will not be giving up my Xeon Cheesegrater any time soon. If DP11 has Xeon bugs, then I will be off of DP again for a few more years...I'd like to know the answer for sure, but I think there is a lot of OCD madness and speculation happening about MIDI recording offset simply because the extra latency of a large buffer clouds the issue tremendously.

[smashprod]

Please, dewdman42, don't confuse the issue, the MoTU engineering team has acknowledged both the problem and the cause. I have it in writing. It IS a verifiable bug. The problem is just that they are blaming it on the CPU. If enough of us cheesegrater users complain, maybe they will consider a fix or workaround.

On the MoTU site, here are the literal tech requirements for DP11:
"Intel Core i3 or faster (including equivalent AMD or Apple Silicon devices)"

As I mentioned, the Intel Xeon "Westmere" CPU found in the 2012 Mac Pro was a faster CPU, introduced the same year as the Core i3, so it meets MoTU's tech requirements.

[dewdman42]

Please, dewdman42, don't confuse the issue,

Please read what I wrote before writing if off. I am adding light to the situation which has not been considered on this thread at all. I am not privy to whatever discussion you say you had with MOTU tech support.

the MoTU engineering team has acknowledged both the problem and the cause. I have it in writing. It IS a verifiable bug. The problem is just that they are blaming it on the CPU. If enough of us cheesegrater users complain, maybe they will consider a fix or workaround.

I'm very skeptical about that excuse. It would not be the first time a tech support person told me BS I didn't believe.

On the MoTU site, here are the literal tech requirements for DP11:
"Intel Core i3 or faster (including equivalent AMD or Apple Silicon devices)"

As I mentioned, the Intel Xeon "Westmere" CPU found in the 2012 Mac Pro was a faster CPU, introduced the same year as the Core i3, so it meets MoTU's tech requirements.

alright... Faster or slower has nothing to do with it.

[bayswater]

Nobody has really mentioned so far in these tests either what kind of MIDI interface they are using. If MOTU or not(with MTS).

USB MIDI drivers probably timestamp in software and who knows what is happening there...but if this bug has been around since 9.x...then its not related to the CPU directly...though its certainly possible Apple has introduced something into class compliant core audio usb MIDI drivers that might be broken with Xeon.

But since this only happens when there is a VI connected, I don't think that's it. its almost certainly a calculation error in DP somewhere.

I used a Roland A49 directly connected via USB to the Mac Mini in the first tests. Later I used Logic Pro to generate MIDI and recorded in DP via IAC. I got the same result, with an additional delay of a few msec with or without VIs using the second method. (Although this was still within 1 tick with DP and Logic running at 120 bpm, and at 480 ticks per note.). I’ve also tried it using the Mac keyboard to generate the MIDI, with the same result. At a buffer of 1024, the use of a VI consistently delays the position of recorded MIDI by a clearly noticeable and consistent amount.

[bayswater]

also I question about the use of IAC to track down this problem. When MIDI is routed over IAC and back into DP, it would be normal to expect that the MIDI would go out and back in during a later process block buffer and would be late.

Its also safe to assume that DP is making some assumptions that since you are hearing audio delayed from buffer latency...that the MIDI should be sent out to IAC late also...which is why it loops around and records late again... That would not be a bug!

The only way I can think of to properly test MIDI track recording offset would be to setup a microphone next to your keyboard so that you can record the sound of your finger hitting the bottom of the keybed as well as the sound of the VI coming out of your speakers! if you can use two mics to isolate the keyboard click from the VI sound even better... and record that to an audio track at the same time as you are recording the MIDI to a MIDI track..(with a VI involved).

But even that test may not give results that should be considered a bug per say... depends on what MOTU is attempting to do. if you have latency while recording through a VI, then DP may be assuming that you are listening to a delayed instrument (due to latency)...and the human tendency is to play ahead of the beat in order to compensate for a latent instrument. We move our fingers early, so that we hear it on time. In such a case, the expected behavior of DP would possible be to offset the recorded notes to the MIDI track later in order to line up with when you actually hear them. That is how LogicPro works I can vouch for that after I ran through my own OCD head trip over WTF is happening with MIDI record offset there. That would not really be a bug per say.. But anyway the point is, with the microphone test, you would detect this without involving IAC which could bring its own timing problems not to mention an additional complexity related to the PLAYBACK timing....and what we are dealing needing to test here is the record offset timing of MIDI tracks.

The point is the delay is present with the use of a VI, and not present without a VI. This happens with IAC, a MIDI keyboard, or a Mac keyboard. There is no noticeable delay using IAC if there is no VI in the chain.

[bayswater]

and one more thing about the large buffer setting. Generally speaking, DAW's always use a very large buffer setting for all non-record-enabled tracks. always regardless of the setting you set in preferences. The setting we set in preferences generally only affects the currently record-enabled tracks.

So what I'm meaning to say is that generally speaking, what is the advantage of running a large buffer setting while you are trying to record MIDI tracks?

I also do not know the internals of DP as to whether they always use a large buffer for non-record-enabled tracks. I know that for LogicPro, that is the case. I know that for Vepro plugin, it imposes an even bigger buffer when its not record enabled, in the form of extra plugin latency, etc. The DAW's do this kind of stuff behind the scenes.

So generally the buffer size preference should only be affecting the track you're trying to record to. It would drive me mad to try to record to a MIDI track with the buffer setting at 1024, that is just way too much latency and I would never be able to trust the timing of whatever I played on a MIDI keyboard. And I question the usefulness of doing so unless the particular VI I am trying to record happens to be a very CPU hungry VI that needs a bigger buffer to avoid drop outs while recording that track. The rest of the tracks that are not record enabled, SHOULD be unaffected by the buffer setting.

So anyway, I will run some tests tonight...but part of me thinks this so called "bug" being discussed may not actually be a bug, but rather intended behavior.....but its just that with a large buffer setting...the latency messes with your head while recording, as simple as that. I've seen these same kinds of discussions on the LogicPro forum in the past for years. But if there actually *IS* some kind of bug that has been introduced we should try to track it down, because I for one will not be giving up my Xeon Cheesegrater any time soon. If DP11 has Xeon bugs, then I will be off of DP again for a few more years...I'd like to know the answer for sure, but I think there is a lot of OCD madness and speculation happening about MIDI recording offset simply because the extra latency of a large buffer clouds the issue tremendously.

If you look at the tests I did, you’ll see the delay is directly related to the size of the buffer. It is there at a buffer of 16 samples, but its about 3 msec, so of no consequence. Note this happens in a project with one MIDI track and one VI track or several MIDI tracks and VI tracks. The delay in the recorded tracks is not related to the presence of other MIDI or VI tracks.

Also, note that MOTU has been able to repeat this, and apparently can reproduce it in Live. I have not been able to reproduce it in Logic. I’ll going to try it in Mixbus at some point.

[dewdman42]

As I have tried to explain, in some cases that delay is intentional, not a bug

[dewdman42]

Secondly the reason two tests, one with or without iac, produce the same delay could be for entirely different reasons and just coincidence that they are the same amount of delay. Introducing iac and/or MIDI clock increases the complexity and makes it harder to pinpoint what is going on.

In the case of iac, there can and will be delay by at least one buffer of time by sending the MIDI out to iac and back into dp or any other daw. This is not noticeable at small buffer settings but will be much more noticeable with a larger buffer setting.

Also playing and recording are two entirely different areas where the daw has to make decisions about timing. By using an iac loop, we don’t know if the delay is caused by playback timing which has been adjusted to match the vi which is going through the output buffer, or if it’s the record offset; an entirely different thing that determines when in time to register incoming MIDI events in the MIDI track. Could even t be both or either, we don’t know. Iac clouds the issue. Just this morning I was helping someone in logicpro to use iac for looping around and I could hear noticeable more latency using the iac loop compared to direct, even with a smaller buffer size. Iac between apps is fast enough but looping around subjects the MIDI events to intentional adjustments being made both on playback and record to line things up with what you are hearing through your speakers.

The MIDI clock test eliminates DP’s play but it does also bring in logicpro’s play timing rules which also may or may not affect MIDI clock timing correctly or incorrectly. So again more complexity that doesn’t pinpoint things.

The best thing is to isolate the situation to record off offset only, no loops and no other daws. Record with a mic and MIDI at the same time. Observe the various results with different settings about the record offset. Make sure you have calibrated audio timing also before doing this test because if that is off then everything will be of

[dewdman42]

The reason it’s only happening when there is a vi in the chain is undoubtedly because that is when dp detects that you are not using external MIDI but rather you are using an internal plugin which will be subject to big buffer delay. Dp is rightly lining up the MIDI to match what you hear.

The fact that the timing of MIDI is totally fine without a vi in the chain only emphasizes that probability and precludes the possibility that a Xeon cpu is somehow not able to keep up with MIDI input. It has nothing to do with that.

Ask yourself a question. Should dp register MIDI in the track exactly at the time you played it or the time you heard it? They one setting is most likely flipping between those two modes. But I suspect there is more to it then that because dp and other daws are taking into consideration the actual metronome you were listening to when you played the part and the metronome is also subject to buffer latency. Daws take all this into consideration while calculating the record offset. It’s possible they introduced a bug in that calculation. It’s also possible everyone is confused by iac loop and MIDI clock tests that are clouding the results in ways that are hard to understand when in fact it’s working perfectly well. I don’t care what Matt @ motu may have said I am extremely skeptical that any of this has anything to do with Xeon processor. Different results in different setups could be from any number of things including how the results are interpreted