I play a Halion4 Piano patch via an M-audio Oxygen49 that is connected to my pc with a USB chord.
I set my audio buffer to 256 samples.
While I am playing I don’t have any noticable timing isseus. So happy camper, let’s play a few bars.
I enable the clicktrack and start playing to the beat, that (to my own judgment) is fairly on the beat.
I hit stop and go in the editor.
Now I see that the whole part is moved backwards in time. Now, latency is a lag of audio or midi right?
So if you have high latency the things you do should apear later in time. How is it possible that what I play appears earlier in the editor?
I enabled click and made my best effort to play fourth’s notes for a few bars.
I went into the editor and the notes were plusminus all around 022 to early on each beat.
In the projectpage I selected the container and added the 022 in the info line and it went well.
I experimented with playing more complicated stuff and it’s all working now, so I have a sort of solution since the beginning of this thread. The 022 is not milli seconds btw, it’s the bars and beats time info, don’t know what that is called.
So I couldn’t exactly measure the amount, I did it a bit quircky, I am not a mathwizzard so…
So. The latency is not between the player and the DAW but maybe the DAW reporting a position encounters internal latency on the round trip between itself (to the processor, the graphics redraw etc.) and itself?
In musical terms this mostly doesn’t matter but in some technical sense maybe it would.
Really, there must be both. There will be a delay between pressing the key and Cubase receiving the midi message.
Since the audio output of a VSTi is subject to the control of Cubase’s plugin delay compensation (PDC) … just as every audio channel sending to the master bus is, after the midi is recorded in ‘real time,’ it will still be ahead of the audio, because you aren’t hearing the audio in real time, but with the delay not just of latency of the system, but also PDC.
You were playing to what you were hearing, but what you were hearing was delayed. So why does the midi note show up early instead of late? Because as you adjusted your playing, the midi note still had to get there before it could trigger the sound of the VSTi you are playing against. It is the played sound which is delayed, not the recorded midi note. So the midi note must be earlier!
This comes back to what Joel reasonably asked. If when recording midi and monitoring it through Cubase, all sound output is delayed by the highest latency plugin, since Cubase does know this PDC, why can’t there be a simple way to adjust the recorded midi?
Here’s one good answer. Not that you couldn’t, but that you might not want to. It the highest plugin latency was from the midi triggered VSTi itself, if you move the midi notes forward in sync with the beat, on playback the notes of that instrument will now be late and no longer sync with the rest of the project … as they did when you played it.
The input delays are small and probably no greater than band mates listening to each other across a stage. It is the output delay that messes things up.
I’ve thought about this a lot and could be totally wrong … but I don’t think so.
Thats a great test that should objectively tell us how good Cubase records MIDI. Should be done first at the lowest latency setting and then at the highest, to see itf it really has an impact on how early the notes are recrded or not.
I cant do it, dont have the equipment. Could anybody do this please?
I agree with the OP on this. Cubase should be able to compensate.
The argument raging here is I believe due to a few misconceptions.
Firstly, playing through Cubase is obviously affected by latency.
Secondly, exsisting midi parts are subject to PDC by Cubase. Cubase does trigger notes early ONCE THEY ARE IN PARTS to compensate for known variables (overal system latency plus any user defined latency in the external instrument plugin interface).
Thirdly, and crucially, a musically aware user will naturally compensate WHEN PLAYING IN for the delay of the system. This explains the incorrect early midi data. Be clear here - the user is naturally playing ahead of the beat. The human brain is smart.
Put these facts together and you have a situation where Cubase is behaving on the (erroneous) assumption that the recorded MIDI is positioned where the user wanted it. It’s not. It’s early, by a time factor that involves the latency of the system at the time the MIDI recording was done. Add to this that Cubase is also playing these DATA earlier than displayed on key edit, as it must compensate for the system delay on playback.
The OP is absolutely correct. We need Cubase to (perhaps optionally) recognise that the “talent” is playing early by an easily calculable amount of time.
I am plagued by this every day of my life (on Nuendo actually but I’ve tested Cubase too).
Turning off PDC during record slightly helps, as the “talent” is now compensating by a smaller amount.
The situation affects all flavours of MIDI be they plugins or external instruments. The mileage may vary between the two owing to the different sums of latency in each case.
Before we get mired by our own ingenuity here, and forgive me if I’ve forgotten it’s been pointed out, do these anomalies involve just the numbers onscreen or are they also aural?
Why? All my midi sounds fine here and if somethings out I rarely look at the numbers. Now, my question is: Is the midi actually out or just the numbers in the Info Line reading erroneously?
(and I know the midi always has latency, thanks)
But you leave out one part. If the midi data from a track played against a project is now moved forward (to the right on the timeline) to sync to the grid, if you play the project back using all the same tracks and VSTi you used to record in the first place, the midi data will now trigger that same VSTi late on the beat, no?
Is it most important for the midi data to look right or to sound right in the context of the project in which it was recorded?
I think everyone can figure out that answer.
Now, if you are recording multiple passes, each with a different VSTi, some of which have the highest PDC latency in the project and you want to create a new midi file of all the parts for export for other uses, then, yes, you will have to adjust all the tracks to the beat. And, for that purpose, presumably Cubase could keep track of some adjustment for each midi track to sync each one individually to the grid.
Please tell me if I have violated any rules, and I will immediately delete this Video.
My purpose is only to make clear what I wish to be fixed since there is a huge confusion about this.
You have illuminated an issue that makes me feel a lot better about my playing. For years, I have thought that trying to compensate for latency has made me play everything early, as per the MIDI results…now I think perhaps not. Hmmm.
Looking at your specs that says, you’re using a fine MAC we can also presume that all the discussion about windows and timing and stuff is quite irrelevant here.
We’ll see. I’m going to try to reproduce tonight. How are you recording your audio-are you sending the track to a group?
Also, just for consistency, what sound card are you using and what was your buffer setting when you did the video?
If I’ve understood correctly, the reason your playing was on the beat (the click) - in spite of latency - was that you were doing what would be expected of a musician, and playing ahead of the click to make the instrument sound together with the click?
Some organists have to do that all the time, in effect always playing with tens of miliseconds latency - eg, apart from a lag between the pressing of a key and the corresponding pipe(s) beginning to sound, the organ console can be tens of feet from the pipes - meaning tens of miliseconds just for the sound (once started) to reach the organist’s ears. It’s a skill acquired through playing (eg pianists transferring to the organ learn to adjust to the lag and can then play as if there were no lag), and …
… as this thread shows, this skill is clearly just as relevant to DAW users.
Unfortunately, apparently, Cubase currently seems fixated with logging a MIDI note at the instant when it’s played, rather than at the moment when Cubase outputs the start of the sound of the note from the VI. For those players who have acquired the skill to make the VI’s sound co-incide with other audio, in spite of the latency, it would be useful if Cubase could delay the placement of the MIDI note to the instant when the sound of the note starts. Then (if I’ve properly understood), for playback, the normal DAW methods of compensating for the different latencies of different VIs (and FX) would ensure that the MIDI notes would then play in time with what was already recorded (instead of early, as in the video).
Because it must. First the note input and then the sound output. If it logged it as the sound you hear begins, then when you played back what you just recorded, your playing would have to be behind the beat of what you had heard while recording.
I don’t disagree that Cubase could and should track the PDC to make adjustment available. But I do disagree that the default behavior should be any thing different than it now is.
I watched the video and the behavior is expected. The slight difference between the playback of the VSTi against the click is the difference between where it should be to remain in sync with the project, i.e., click, and the playing.
Say, if you use an external synth or keyboard, using that sound to listen on while recording on your VST instrument track, then I agree with you Como. And it has to be said, when recording on midi tracks routed to outboard midi gear, it shouldn’t be different from now.
But regarding VST instruments - I might think even the default behavior should be different from what it is now.
However, if they would change the default behavior or not is not so important to me, I could live with “activating” the functionality for this. I’d probably celebrate it with sparkling wine and have activating cake with my friends.
This explains a little about how the test was done:
I don’t think it’s so important for the matter but it
could be useful if you’d like to test for yourself.
First I created a VST instrument track, a group channel, and an Audio track.
On the VST instrument’s output channel I activated a “send” (copy) to the group channel.
Then I set the audio channel’s input to the group channel .
I record enable both the VST instrument track and the audio track.
This test is made using a Frost Autumnleaves PC and the soundcard is a Focusrite Saffire Pro 26 I/O. Windows 7 64 bit running Cubase 32 bit. The latency on the soundcard is set higher than usual to give a more clear picture of the problem: The ASIO Buffer size is set to 40 ms giving me an Input latency on 41.6 ms and an output latency on 45.5 ms.
I have to say though, that even on my soundcard’s smallest ASIO buffer size setting, 4 ms giving the input Latency 5.6 ms and the output latency 9.5 ms, this is a problem too. I wouldn’t bother to lay time on this thread if I didn’t feel that way. Notes still doesn’t playback accordingly with how it was played and all data seems to be placed a bit too early in comparison to the “take”.
@Joel: I watched the video and I can confirm that the scenario you shown, I have been plagued with that for many years. You learn to get by, but this needs some developers attention for sure. No matter what system MAC/PC the same results have been like that for years. Back in the SX2,3,4,5 days, Many keyboardist would complain to me about this very situation. You can fix the notes but, why should you have too…
Yeah Joel! Thanks for the video. Now, somebody earlier said:
“I watched the video and the behavior is expected”
Man, did you watch the same video? Do you expect the sequencer to record with bad timing? Do you expect you have to move your performance EVERY single take you make? Jeez…