Negative Delay CC Curve Issue (with example project)

Cubase
,
1

It seems that this exact issue may have been reported before but went without meaningful investigation or solution:

I’ve made a minimal project equipped with MIDI Monitors to demonstrate the issue. The screenshot shows the results across tracks with deep negative delays (and one without to compare). It seems the nodes of the CC curves ( not the generated events between the nodes) are causing issues with some “prefetch” buffer when the negative delay is substantially increased. Also, the issue seems to worsen if the “MIDI Latency Mode” in Edit > Preferences… > MIDI is lowered; however, I could only recreate that having any effect with my actual orchestration project, not with this simplified example. Bringing the setting to it’s max (“High”) did practically nothing for me, and the screenshot here was generated with the setting to “High” as well.

TrackDelayCCs
TrackDelayCCs1739×1743 251 KB

The more nodes used, the more opportunities there seems to be for scrambled CC data. The misbehavior is also consistent throughout each playback (no randomness).

For me, this is causing erratic MIDI CC behavior for a sample library capable of utilizing a 400ms lookahead (Modern Scoring Strings by Audiobro). The MIDI Monitors reveal a lot of out-of-order events, and some events aren’t even arriving in the order they’re “positioned” (according to “Position” column). The out-of-order-ness of this is also apparent when using an external MIDI monitor as well (Kontakt factory multiscript) which verifies that this isn’t just a bug of Cubase’s MIDI Monitor effect.

Hopefully I’ll be able to provide enough info so the devs can perhaps get to the bottom of this one. I’m aware that these CC curves are relatively new to Cubase, so it could be as simple as an uncaught oversight. One can hope.

Screenshot (mistakenly) taken in Cubase 11.0.20, but I’ve gotten the same results in Cubase 12.0.20.

In case there are issues with the project file (as I’ve never shared a *.cpr file before), the project is just 3 MIDI tracks named after their negative delay values each with a MIDI Monitor MIDI insert. Each track has the same MIDI data: no notes, just the CC data as shown in the screenshot. Also, each track has both their Input Routing and Output Routing set to “Not Connected” as an attempt to exclude the influence of other MIDI devices. There is a measure of silence before the shown MIDI plays (necessary given the large negative delays). Tempo is at 100bpm though it doesn’t matter if it’s at the default 120bpm. I’m pretty sure that’ll get anyone a solid recreation of the project.

TrackDelayCCTest.cpr (121.5 KB)

2 Likes
2

Still occurring on the just-released update to 12.0.30 (lazy excuse to bump, forgive me).

Is anyone able to reproduce? Is it just me? Is this a bug or PEBCAK?

3

In case anyone happens to find this and are having the same issue, I’ll share a workaround: utilizing a VST negative-delay plugin that takes advantage of Plugin Delay Compensation (PDC) to apply arbitrary negative delays to any audio stream. By removing the negative delay from the midi/instrument track and adding such a plugin to the output audio track as an effect, you can get the desired effect as long as PDC is being respected.

There are two free options that I’ve found that seem to do the trick:

  1. MinusDelay by Bakuage which features plus-or-minus 400ms of delay but doesn’t make it easily to dial in specific, numeric amounts. If targeting any value other than exactly -400ms or +400ms, you may benefit from linking a DAW controller to it that allows numeric input (you’d have to do some math conversions though as I think naïve controllers will display values from 0 to 1, so 0 is likely -400ms and 1 = 400ms with 0.5 for “no effect”). I’m still quite new to Cubase, so there could be a more elegant means of handling this that I’m unaware of.
  2. Voxengo Latency Delay though it seems limited to 10k samples of negative delay or about 227ms at 44.1kHz (it’d be less at higher sample rates).

To reach deeper delays, plugins like these can be stacked. It won’t be all that tidy but it’ll work.

While pushing the midi back is an obvious “solution”, it’s imprecise, will drift from BPM changes (since event positioning is musically timed, not absolute), renders the musical grid useless (not always an issue), and allows the playback cursor’s position to not align with what you’re hearing (which is quite unsatisfying). The VST effect trick will do until I figure out what I’m doing wrong or this is recognized as an issue and is eventually resolved.

1 Like
4

I think the issue is not fixed, yet. But if you just don’t use bezier curves (line/curve function) in midi cc data, it should work properly.

When I was recording, everything worked fine, but when I added 1 bezier point to the midi cc 1 lane, the modwheel started to shake. (negative track delay of -250ms). When I drew in a step curve with the grid of, it worked fine. So I think the problem is in the midi cc bezier curves, which are kind of new to cubase.
Btw. the midi monitor did not read outside prefetch data when delaying in the positive direction, but the modwheel (which I was controlling at that time) did shake around the same way as it did with -250ms track delay. So I think you can ignore the prefetch maybe.
Maybe this helps anyone until Steinberg fixes this issue.

5

Has this been fixed in Cubase 13?

6

I wanted to comment that the plug-in Voxengo Sound Delay is also free and it’s a better version of Voxengo Latency Delay that can delay in miliseconds (far easier to use than samples) and has a much higher limit.

7

Voxengo Sound Delay doesn’t do negative delay (or at least, I couldn’t find any claim that it does) which is why I didn’t mention it originally.

Also, Voxengo Latency Delay measures in both samples or milliseconds (look at the UI); its limit is measured in samples so that its ability is oddly affected by sample rate. I don’t prefer it, but it’s precise. I think there are more options out there, but I haven’t been motivated to keep looking for them.

And since I’m replying, I’ll also mention that I don’t know if it’s been fixed as I haven’t been persuaded to update to Cubase 13 (I’ve been working on non-music things as of late, but Reaper has been my preference).

1 Like
8

You are right, sorry for the confusion and thank you for the clarification!

One question: does your workaround work if you put the latency plug-in in VEPro Server (which would be in turn connected to Cubase) instead of Cubase itself? I’m pretty sure VEPro has latency compensation too but I’m not sure it can be ‘‘aware’’ of the MIDI information coming from Cubase before hand (unlike Cubase which is aware because it can see ‘‘lookahead’’ in the project).

9

Actually, I’m not sure. You’d have to try it. If VEP can handle PDC track-per-track (within itself) and report the max latency to the host (Cubase in this case), you’d be fine. I have no idea if it does this though.

To be “aware of the MIDI information coming from Cubase”, as you put it, it only needs to report its latency to Cubase. For example, if it reports 400ms of latency to Cubase (because internally the max latency is 400ms in this case), Cubase should send MIDI 400ms ahead of time because that’s the only way it can generate audio 400ms ahead of time for said MIDI. Having not tried this myself, I could always be wrong, but that’s what I would expect (assuming it works at all).

Maybe you should kick up some test projects and let us know how it worked out. I’m not really in this game anymore having mostly moved on, but I’m sure others that are still invested in this issue/topic would appreciate your findings.

1 Like