MIDI notes recorded earlier than they sound

That´s what I meant…

This is a problem of old which had been fixed.
My theory is that whatever caused it was part of the development process but conflicted with something in WinXP. Now, with their announcement about a year ago of dropping support for WinXP they think that only a few are using XP so they’ve reintroduced the process.
Keep an eye on other posters with the same symptoms for a couple of weeks and if none turn up get yourself Win7. (sheat! just noticed you seem to have dual boot, sorry but still, as before but sack the XP, keep the W7. Can’t see the specs when I’m writing the replies)
Or check “Use system timestamp.”
Cubase does not cause latency. Data round trips through the computer cause latency.
What are those M-Audio drivers like lately? Sometimes, like the Emu I use the latest drivers can be the problem and I have to revert back to an earlier one. Is the M-Audio Control Panel set up OK?

Windows 7 is not the solution… I have windows 7, I have also had this same problem since I started using cubase… I have just learned to live with it… even low latency isnt perfect. notes are always recorded early regardless.

I wonder if the UAD is part of the problem… I also have a UAD…

also I have had this same issue through 3 different PC’s / soundcards.

i’m also convinced most people have this same issue but don’t realise… so here is a test

  1. add a vst instrument to your project, a synth for example with a fast attack
  2. add a group channel
  3. route vst to group channel
  4. add an audio channel
  5. set inputs of audio channel to be the group channel
  6. enable record on audio chan and VST instrument
  7. start recording
  8. play a single note.
  9. stop recording
  10. zoom in to see the waveform / midi

now, is the midi significantly earlier than the audio ?

Xtigma, thanks for your input!

It will be very interesting to see the results of this!
Here, at a buffer size of 256 samples, my MIDI note is 8 ticks earlier than my audio :frowning:

I run into this all the time. AFAIK, it is purely a latency/buffer size issue. When playing virtual instruments, you need the lowest buffer size your computer can handle in any specific project to hear and record notes close to where you actually play them. This has been the case since I started using VSTis in Cubase, back in 1997.

good to know, although I would have thought it would be fairly easy for cubase to compensate the Midi… seems a bit strange that it doesnt!

…but it works OK in Reason… so that rules out the hardware and the size of the buffer.

A couple clarifying questions though…if you have no UAD plugins present, does Cubase then record on time and play on time, just as your say Reason does? Are UAD plug-ins the only ones that cause this behavior? (as opposed to a high-latency native VST)

Even with no UAD plugins running, Cubase does not compensate for the latency of my sound card.
The example I quoted earlier, using Xtigma’s test, was done under those conditions.
Empty project, with no plugins of any kind running, buffer size of 256 samples, my MIDI appears 8 ticks earlier in the sequencer than the audio.

Any high latency plugin (UAD or other) will cause the distance between MIDI note and audio to increase…

Fizbin/everyone else… could you try Xtigma’s test yourself and report your findings?

Using the init patch in neon in Cubase 6.05 x64 on a Windows 7 PC, no inserted FX anywhere, the rendered waveform of the MIDI note began rising literally on the first sample possible - aligned perfectly with the MIDI note. I repro’ed this at 64 samples and 2048 samples. No difference.

Inserting Cubase Cloner (latency 5700) as an insert on both the group and the neon output and turning the mix to 0 in both instances, made audio render about 2600 samples early. Removing either instance of cloner removed half that offset in rendered audio. The early audio offset effect here was the same whether the latency on my card was set at 64 samples or 2048 samples.

Interestingly, engaging “Constrain Delay Compensation” and then recording with the high latency plug-ins caused the waveform to render exactly as expected on the first sample aligning with the MIDI note.

Something is messed up with the delay compensation. This has nothing to do with incoming MIDI. I dropped the note in by hand snapped to grid.

EDIT: I now believe the natural behavior of Cloner is to move the dry signal forward in time, so this may be by design.

wow… just to clarify, you were recording the midi and the audio at the same time yeah? you diddnt place the midi note then record (sorry im 99% sure you diddn’t I just wanted to be 100% sure before I start replacing every part of my entire studio to get to the bottom of this problem!)

this is how mine looks


Wow fizbin that’s completely bonkers.

If I draw the MIDI note into the sequencer, then hit record so that the VSTi is recorded onto my audio track, then the two events appear in the sequencer at the same time (but we already know that delay compensation works correctly for audio export, otherwise there would already have been a riot!)

It’s only when I record via MIDI keyboard that there is a distance between the two notes, in which case it looks exactly like xtigma’s screen shot with the MIDI note early. The exact distance changes depending on latency, which makes prediction of a compensating shift very difficult.

So there’s a subtle difference between xtigma’s test by (a) drawing a note in the sequencer with the pencil and (b) playing it from a keyboard… it’s the results from test (b) I’m most interested in :slight_smile:

I’d now try a quick email to support, pointing to this thread, and see if you get any joy there. I think we’re all stumped here at the minute.

I think it’s possible that the natural behavior of Cloner is to move the dry signal ahead now that I think about it. Might be by design. Then there’s a little room for the cloned notes afterwards, making a cluster around where the note actually occurs. Why else would a cloner, which is little more than a modulated delay, have such a high latency reported. Try it and see for yourself.

I’m calling my experiment results tainted.

I’ll try again with a differen plug-in. A lookahead compressor (high latency) shouldn’t be moving the dry signal.


I did this, and got what I think are the same results:

  1. If I play a MIDI note on my Motif (USB MIDI connection), record it, and also route it through HSSE >> Group >> Audio, the audio reproducibly begins on the track after the MIDI. I did this 3 times, and got values of 9, 9 and 6 msec.

  2. If Instead I just record the MIDI note, then play it back with output to HSSE >> Group >> Audio, at the highest zoom the audio still appears after the MIDI on the track, but less so (less than one tic (msec) later).

The only explanation I can think of is that some small amount of time (roughly 8 msec) is needed after a MIDI note is recorded onto the track before Cubase is ready to route it on to the soft synth. If the MIDI note has already been recorded on the track, and playback is used, Cubase has the brain cells to handle the computation more quickly/almost immediately. I guess that wouldn’t be surprising if it were true … ?

Thanks for trying that out, alexis

So far it seems that cubase does not correctly compensate for latency / plugin delays when recording MIDI.
(Unless someone can take Xtigma’s test and prove that their MIDI and audio do in fact line up exactly?)

I have now contacted tech support about this thru the support form

Still waiting for tech support to get in trouch (are they normally this slow?)

In the meantime, could some more users please try Xtigma’s repro (on previous page)?
Especially those of you who think your MIDI timing is perfect :slight_smile:

i got a reply from tech support… they just suggested i enable system timestamp… i replied saying that it didn’t matter… no response

(Unless someone can take Xtigma’s test and prove that their MIDI and audio do in fact line up exactly?)

Mid and audio will NEVER line up exactly. They go through different parts of the system so it will always be random exactly to the nth where they get spit out.
Mind you, I think in this case, if you can easily detect it and it affects your system and your ears then something is awry somewhere. In common practise it should not be easily detectable.
Though, if I remember and can’t recall if it’s still there (or where) or not you used to be able to change the ppqn midi resolution which might make a difference. I’ll have a look around.

I am not talking about tiny timing differences here. A few milliseconds I could live with, but I am talking about much larger distances - take a look at Xtigma’s screenshot. 150ms + is unacceptable.

Anyway MIDI and audio do line up exactly (within usual MIDI timing limits) - on playback and export. Cubase knows its VSTi’s latency and compensates for it (otherwise, the audio exported from all our VSTis would be late and the forum would be swamped!)

When recording MIDI, I believe Cubase IS compensating for the latency by moving each MIDI note earlier in time, by a distance equal to the overall system latency. This is why the note appears at the moment in time that it was first hit, and not when the sound came out the speaker.

However, this means that the MIDI note and the audio generated by that note are no longer in alignment - because Cubase moved the MIDI, but not the audio!

So what I need is for Cubase NOT to move the MIDI when recorded. Just leave it where it is. Then it would be lined up with the audio and all would be well - it would sound EXACTLY the same on playback/export as it did when I recorded it - result!

i.e. we need to turn the delay compensation OFF not ON, because “ON” only does half a job !
When I play ahead of time, then I AM the delay compensation :smiley: