Problem : There is a HUGE discrepancy between recording Audio and Midi in realtime mode with buffer settings depending on device.
Reproduce :
Create new project
Set buffer setting to a mid or long level to demonstrate the effect visually
Create a new Midi Track and setup a working midi instrument of any kind to play (no need to setup midi output)
Mic and setup a audio track of you in your room or studio and place it close to your where you will strike your midi instrument so you can record the sound of striking the keynote.
Arm both tracks
Record a short sequence with slow 1/4 notes and view the display
Both recorded Midi note and Audio sound should be very close to one another. Depending on various factors Midi is rarely ‘in sync’ with a audio click track.
Status : pending comment (I have heard rumor that Sonar/Ableton doesn’t record in this manner)
disclaimer: Please this is a discussion intended for Midi Input only. Discussion is constantly diverted due to those offering ‘suggestions’ for solution of problem that is not described here (eg. jitter/routing/natural delay/human error/compensation/loopback tests).
This thread is talking about known system latency shown in Cubase ASIO Device Setup. This problem so far may include certain soundcards causing a bug in Cubase, certain ‘timestamp’ settings or other anomaly which has been proven several times to be true, including this SoS artice from 2003.
In this last paragraph the author describes the problem too a tee.
“Sadly, these tweaks don’t seem to work for everyone. There’s a small minority of musicians that have tried all the options and still suffer from MIDI notes being placed too early in the part, sometimes by a large but consistent amount of several tens of milliseconds. Since such problems tend to happen with a particular combination of components, some people may have had no timing problems for years but then start to suffer when they move to a new PC. Sometimes changing the MIDI interface, or even the motherboard, will cure the problem, but if sequencer developers would offer us a MIDI offset parameter, a single tweak of this could remove recording and playback latency, leaving just the jitter component.” copywrite SoS magazine.
Anyone of you should be able to reproduce this test that shows Cubase records Midi without taking into consideration known system latency. You can measure this by mic’ing your self tapping on a Midi controller in a tandem recording. Try at different latencies. At large latency the problem is the worse, but at low latency it’s less noticable. AFAIK other DAW’s don’t exhibit this behavior.
this is the screenshot:
(this is ~5 ms in difference between hearing the click track (audio) and recorded midi note…
cheers
Doing this will still produce the same early Midi because like I said to play in sync with the metronome, not the produced sound which if anything should produce a Midi that is recorded slightly late!
It makes absolutely zero difference. Are you reading what I’m saying?
Cubase won’t account for ANY known system latency when printing the Midi during a record process. This is the latency reported in ASIO settings (or whatever is used on a MAC).
Again, I’m not talking about perceived latency that you would encounter if you indeed were even monitoring what your recording.
To test this you can turn Off your midi devices, all you need is a single input Midi source. You should also be able to test this by using a virtual midi keyboard by clicking with the mouse.
Okay, I see what you mean now.
Could be done, I suppose.
However,
That’s the entire purpose of the quantize feature.
It can be set to automatic (in the transport panel) and it should eliminate your problem.
Ie: pull the audio back to sync up with the MIDI.
Yes. There may be a problem here but it has NOTHING to do with latency. Latency, as I keep saying but no-one hears, is to do with what you HEAR not what is RECORDED and QUANTISED by Cubase.
Where Cubase places notes has nothing to do with what you hear (which could be anything). It is all to do with what key you press and when.
Don’t be fooled by the extra offset caused by increased buffer size. That has more to do with the player.
When you hit a note Cubase will put it at the closest QUANTISE point it finds after calculating the time it received the midi keypress note.
To prove this turn your headphones and speakers off and play by looking at the screen (yes, it does sound a mad idea). Then check what you have recorded.
In this thread someone made the suggestion of actually recording the sound of keys pressed on the keyboard at the same time with the MIDI (with no output instrument attached). So the OP in this thread did exactly this and came up with definite proof of what we’ve been suspecting (and possibly blaming on our own inaccurate playing) for a long time:
MIDI IS ALWAYS RECORDED TOO EARLY.
You ALWAYS need to move recorded MIDI parts forward. This may be worse with long latencies, but it is still recognizable even with very small latencies.
So, the time when you push a key (as compared to either playback or a metronome) should be recorded. Period. This would be expected behaviour by anyone. We are not talking about intuitive compensation for delayed instrument playback (because there is no output instrument selected).
So, if for some reason, placing whatever you record EARLIER than when the key was actually pushed would be “expected” behaviour (which I fail to see), then you would also expect AUDIO to behave in the same way. So at least, when you record MIDI and audio at the same time, they would also be in the same place, regardless of latency.
This experiment finally (after several years) proves that the Cubase behaviour of ALWAYS placing recorded MIDI EARLIER than the actual point of pushing the key is a BUG. A rather annoying bug that should be addressed as soon as possible.
Other DAWs do not seem to show this behaviour (could someone run the same test on Logic or Reaper?)
BTW: This has nothing to do with any kind of quantising whatsoever. Imagine playing to an audio click without any grid. The erratic behaviour would persist. And no, the quantise feature is not designed to move everything forward.
Oh, I thought the purpose of the quantize feature was to mess with your performance and make the music sound as if a mechanoid played it.
Well, OK, I do sometimes use quantising to improve sloppy playing - but, mainly, what I, for one, want Cubase to do is capture accurately what I play, and not tweak it on the (patronising) assumption that I actually meant to play something else. If my playing wasn’t good enough, I’ll either tweak the MIDI data myself afterwards (with or without the aid of quantising) or re-record to get it better.
I, for one, certainly wouldn’t want everything put through quantising . And, actually, quantising’s not always feasible anyway, because I often record with the metronome switched off, in order to capture the natural speed variations of live playing. AFAIK, I’m far from alone in doing that.
I don’t think the above quote was meant to suggest that we can’t expect Cubase to make a decent MIDI recording unless it’s quantised on the way in, but having to rely on quantising can’t be the solution to MIDI recording problems, except in some particular cases.
I thought I’d make my own thread (although I’m sure there are others over the years), JoelErikson’s thread while demonstrates the issue precisely, his thread is talking about VSTi and his situation and I started to feel like the thread was getting hi-jacked to start talk about Midi recording in general as opposed to VSTi issues.
Apparently Steinberg CS has responded to his issue, but it’s not known exactly what they did recognize as the problem and what they are looking at fixing.
I’m feeling a lot like a cat in wet cloths being a Cubase user at this point, with some users noting other DAW do not suffer from this issue. It would be nice to know that Steinberg can recognize this issue and plan to fix it ASAP!!!
Thanks for the support, I will keep this thread active until we can get a understanding of Steinberg understanding of this issue (BUG).
We’ve all been hearing this discussion for years, so today I thought I would test it out on my system.
I did as the OP beerbong suggested - mic’ed up a MIDI keyboard and recorded both the MIDI and audio, whilst (trying to) keep in time with the Cubase metronome.
i did NOT find that the MIDI recorded early. On the contrary, compared with the audio recording of the key being struck, it recorded some 0.01 second later. This was entirely consistent, whatever the audio buffer (latency setting) I used (64 samples to 2048 samples).
I presume the reason for the the MIDI note being late is the latency of my MIDI keyboard (I used an Oxygen 25, USB’d into the computer).
I have to say I was expecting to find the note to be early, because when I record MIDI along with audio I am usually well ahead of the beat (so is everyone else I record). I assume this is because musicians compensate for the delay inherent in all MIDI systems (even MIDI keyboards using internal sounds, not just VSTis) by playing early.
This has been discussed many times over the years - it seems some systems may produce an inaccurate recording of MIDI data, but mine doesn’t seem to. Isn’t that why Steinberg have an ‘Adjust for Latency’ setting? (Devices>Device Setup>VST audio system’) BTW I have this box checked, but set to 0 samples. It seems to make no difference to this test if I uncheck the box.
I don’t understand Tommok’s statements above (my underline) surely if you have to move the MIDI forward, it’s been recorded late, not early? Or do you mean forward as in the direction of the timeline (ie later in time - to the right)?
Talk of quantising, of course, misses the point completely.
I think the latter – in the several recent threads about MIDI being recorded early, several people seem to be using “forward” to mean to the right (later in time), whereas, in everyday speech, to say “bring the meeting forward” means hold the meeting earlier. (I was confused at first, but got used to it - I now rely on the context to tell whether the writer means the MIDI data must move to the left or the right.)
And the plot thickens… Just to confirm that you have not been automatically compensating without your own realization have you tried the test by just cranking your buffer setting to the maximum of 20 seconds or more?
So far it seems the difference in your case (if true) is your on a Mac??
Can anyone else running MAC confirm that MAC Cubase does not exhibit this behavior?
Perhaps it is indeed having to do with ASIO/Core differences?
Lets see if anyone else can run this test on Mac and PC to see who cannot prove it is true for everyone. Right now this is the sole case which disputes my main claims.
I have to say I was expecting to find the note to be early, because when I record MIDI along with audio I am usually well ahead of the beat (so is everyone else I record). > I assume this is because musicians compensate for the delay inherent in all MIDI systems > (even MIDI keyboards using internal sounds, not just VSTis) by playing early.
Musicians will, especially if playing to metronome, play one side of the beat or the other as if you play spot on you can’t hear the metronome. Actually, if you can make the metronome disappear you are a master of timing.
I don’t doubt there is a problem here but it’s not the one most posters seem to assume.
I’d say that on certain system setups that Cubase is placing notes erratically. They may be regular errata but they’re still errata.
I also remember that some time ago on some soundcards, including Emu for one, had drivers that delivered erratic notes at higher latencies.
There is an anomaly in these threads that people seem to be increasing the latency because they play “live”. !? (or have I misinterpreted something? Just to exaggerate the anomaly found?) I’ll try to keep that in mind.
If you want to play live midi then you turn the QUANTISE to it’s max. 128trips or OFF.
When I do this at normal latency on any DAW the notes arrive as played. Normal latency for me is about 5 - 8ms. There would be no point in increasing it as when I play I want to hear myself at the right time.
Why would I want to have to have latency so bad I have to compensate for it? Furthermore, why would anyone here? If you buy a DAW like Cubase I would suppose that common sense and proper research would tell you that you need an interface and drivers that delivered the lowest latency possible.
It may seem like a retrograde step if I suggested that it could benefit some posters with the problem that they actually reverted to an earlier driver for their soundcard as the fault could be with the newest and see if Cubase shows any improvement or not.
I am on Mac and this problem happens for me as well. Specifically what Cubase does and other sequencers don’t do is it records the MIDI at the timing you played rather than the timing that matches what you heard while playing. So if you are playing a VI that has latency, all your MIDI will be early. This blows because you can never tell whether you played a good performance or not. You will have heard a good performance, but when you play it back, its all early. You can try really hard to play the right timing even though you are hearing all the wrong thing, but you will feel very bizzare.
But there is an even worse MIDI problem in Cubase. It has huge MIDI jitter when you are live monitoring. For example, if you hook up an external seqencer that just plays back straight 16th notes and have it play into a VI track that is record enabled, you will hear terrible terrible timing all over the place if you are at any buffer above 64 samples. Obviously this happens with normal playing too, but using the external sequencer will make it crystal clear to you how bad it is. Sucks…
Thanks for the response, but please not that this Bug report requests that no monitoring of your midi destination to take place. This test is to be either confirmed or unconfirmed by recording Midi while the instrument(s) are muted or disconnected and listening only to the Cubase metronome while recording.
The positive result will be what ffg reported which is a delayed midi recording of 0.01-0.02 ms consistently.
Midi jitter is also not the purpose of this thread report.
The audio buffer range available on my RME system is 32 samples to 2048 samples. I did the test at 64 and 2048 and there was NO difference to where the MIDI note and the audio of the keystroke appear in relation to each other - in both cases it was about 0.01 sec apart (MIDI later than audio). The MIDI keystroke was not triggering any sound as that might well have affected my perception (though it would not have altered the MIDI/audio timing - and of course there was no need to have a click running, as I am simply testing the timing accuracy of MIDI v audio recording.
by the way, .01 sec is 10 ms, not 1 ms.
(edit to say - is there anything else I can test on my system which would throw any light on this?
BTW I posted on the other related thread a couple of thoughts about probably why many folks are suffering from early MIDI syndrome)
And why would anyone want to do that?
And why would they need to? Because their system is not configured properly in the first place for any modern DAW.
Don’t tell me it works on X or Y DAW because the physics will not add up and furthermore it wouldn’t be relevant to this thread.
Jitter is a hardware expression. Originally “the jitters” comes from the physical shakes of alcoholism or being frightened of demons. Hardware jitter is the same but caused by solid componentry vibrating.
Software can’t do that. Software has “glitches”.
If we mix in the jitter rubbish we’ll get even further from solving any problem here. Another matter entirely.
. And, actually, quantising’s not always feasible anyway, because I often record with the metronome switched off, in order to capture the natural speed variations of live playing. AFAIK, I’m far from alone in doing that.