DP 11 makes me sound like I'm rushing the beat. :)

[dreamuse]

I'm noticing something, um, interesting: With the latest DP and OS 11.6.7, when I play to a click, the MIDI data is head of the beat, and is correlated to the buffer setting: At 32, I sound like I'm in the pocket. At 2048? Too many cups of coffee.

I don't remember seeing this behavior in earlier versions of DP, and would figure DP would well know the delay one's hearing to a click, and move things accordingly? It almost seems as if it's over-compsensating, in fact.

With a large pallet and 1024 buffer, I'm routinely having to move stuff back.

Thanks for any ideas, here.

Len

[stubbsonic]

Yea, I think DP is supposed to compensate for high buffers when recording (audio or MIDI). I can't help you with the settings (at this moment) but they do exist and it is a very fixable thing.

[dreamuse]

Encouraging to hear those settings exist. After 20 years of DP, this is a new one for me...

Thanks,

Len

[dewdman42]

This is a known issue. Please make sure to submit a bug report to MOTU as they continue to ignore it even though several of us have tried to work with MOTU to get it fixed.

So one work around at least for now, is to use a small buffer AND ALSO, make sure to set the the following preference to OFF. However be advised that when this setting is OFF, then a large buffer setting will also create a problem when you play along with the metronome.

Screen Shot 2022-10-14 at 12.23.01 PM.jpg (317.02 KiB) Viewed 993 times

[Killahurts]

AND ALSO, make sure to set the the following preference to OFF. However be advised that when this setting is OFF, then a large buffer setting will also create a problem when you play along with the metronome.

I noticed that in 11.2, this was one of the fixes:

* Changed the sync recorded MIDI to patch-thru setting to be off by default *

Apparently, it was turned ON by default previously, and it gave me all kinds of problems recording MIDI. It wouldn't sound like the timing I played, and sure enough, that little box would be set to on.

[dewdman42]

If DP worked properly it would be preferable to have the box checked. What this box means, as I understand it, is that when its checked, DP is supposed to consider when it received MIDI events during record...and taking into account current latency...it knows when you should have heard the metronome clicks and uses that to determine when in time to register the actual MIDI events on the track relative to WHEN YOU HEARD the clicks. So that if you heard the clicks with latency, and played along with what you heard and if you were good enough to play the keys exactly in sync with the audible heard metronome clicks...the events should end up on the track exactly on those clicks....

Not only that it probably takes into consideration also when you ACTUALLY HEARD the sound coming from your soft synth, which also has latency.

When the box is unchecked, then it doesn't attempt to do that..which means that with a large buffer setting, you will be hearing the audible clicks late...and playing late...and the MIDI events would be registered late also..

Basically its preferable if the functionality actually worked right to have it checked. But the record offset functionality is simply not working correctly and registers events wrong, so the next best solution for now is use a very small buffer while recording MIDI and uncheck that box to get rid of DP's currently faulty record offset calculation.

[dreamuse]

Thanks all. Yea, this is really strange. I'm wondering if they also put a bad time multiplier in when calculating the driver latency of one's I/O.

[HCMarkus]

Maybe on point, but I recall discovering that if one changes DP's buffer size, it was vital to disable then re-enable record enable on any tracks on which one is recording. I don't remember what version of DP I confirmed this; it was awhile ago.

[dreamuse]

Interesting: I think I saw this behavior with audio, but hadn't seen it with MIDI before.

[Chandrasekar]

Anyone verified if this problem exists in other DAWS?
I remember a YT video where, the host halfway demonstrating a VST instrument, changed the buffer size from 256 to 32. The sound clarity and sustain of the instrument immediately improved and was also explained so by the host. The sounds suddenly became richer. The DAW he used was different (like Cubase or Samplitude, can't recall).
Regards.

[bayswater]

When this first came up I tried it in Logic. It had smaller errors in the opposite direction. They were not related to buffer size. As for audible differences I’m skeptical. After loads of “invert and sum” tests with different settings and different DAWs I’ve rarely seen anything other than digital zero and sometimes something around -130db. Most of those were explained by different pan laws.

[dewdman42]

Run the test yourself. It’s way way more than audible. It’s patently a bug.

Logicpro also has some latency correction bugs, slightly different then this one.

[bayswater]

Run the test yourself. It’s way way more than audible. It’s patently a bug.

Logicpro also has some latency correction bugs, slightly different then this one.

If you’re answering my post, I’m not saying you can’t hear the “bug”. It’s clearing there and quite annoying, esp. if you’re tracking something. I’m saying the rendered audio quality is not affected, even though the timing is.

The latency correction errors in Logic are there as you say, but not quite as apparent in normal use. Although it has a not so great reputation for MIDI, I don’t see this problem in Mixbus.

I haven’t updated to DP 11 yet and this is still there is one of the reasons. If and when some of these things get addressed, I’m all for it. For now, quite disappointing.

[dewdman42]

oh yea, sorry if I misunderstood. I agree, audio quality is completely unaffected.