Depends what he saw. Maybe you missed something. I mean to put that into perspective, for myself I can sometimes worry about a brick without noticing that the whole wall is wonky.
I think now, and lean towards Como, that this is a quantisation problem more than a latency problem.
First off though, not all Cubase users have to move their performance after each take, certainly I don’t and if I do it’s usually because I played it that way.
Check the quant settings and see that they are exact. Either you may have made changes to the templates (while experimenting with a new Cubase) or the quant templates you have downloaded are not perfectly set. ie: 1/16 may have an offset set for a looser feel and as people frequently overestimate their timing talents (mine are extremely good but not as good as I think all the time) any discrepancies are compounded and very annoying to correct.
Conman,
With all respect: If at this stages of the thread, and i know you´ve been active on the other one about this in the forum too, you come here and talk about quantization i think i am gonna consider you a troll buddy.
So 
Unless a tornado draws me back into the discussion again,
I’d like to say just a few more words.
The video example is recorded to showcase the problem,
and is therefore performed with a higher latency than usual.
Maybe there was some misunderstanding earlier but
to make clear, I don’t use any quantize there.
When recording VST instruments with lower latency, the problem shrinks accordingly,
but doesn’t disappear. I often have to move forward stuff to compensate.
Especially when it comes to live playing and I don’t want to quantize,
but also at times when I intend to quantize right.
Seems like there’s a bunch of people out there who’d love to see this work properly.
It could be a setting in the preferences at least. Maybe most people wouldn’t bother,
while others would see it as kind of groundbreaking.
Let’s see what they say at the support.
Thx!
/ Joel
Hi All
It’s a sticky little problem this, isn’t it?
The main issue that is blocking some readers from fully grasping what is going in is, as I stated earlier, that Cubase IS COMPENSATING FOR LATENCY ON PLAYBACK. By this I mean, if you step imputed a bunch of notes on the grid, it would play in time with the click. Is this just by magic? No. Cubase plays the midi data EARLIER THAN DISPLAYED IN KEY EDIT to compensate. It’s in the manual (somewhere).
Now, this (MIDI PDC) is clearly impossible during a MIDI recording. (otherwise Cubase would have to predict what you are about to improvise). The problem arises as the musician naturally played early to compensate. But Cubase then ADDS ITS COMPENSATION on playback once the recording is done and a midi part is created.
This is really the error going on here. Think about step imputed notes and why they do not play late.
What Cubase should really do is, once the recording is done, shift the midi DATA forwards (ie later) by the exact same amount as whatever it’s PDC engine was set to during record. In effect, Cubase should recognise that any midi events arriving at the midi port are early as a result of the player playing in time with what was audible at the time of record.
I really hope that Steinberb will pay attention to this very long standing and massively time consuming design flaw. Yes perhaps that’s the word to use if SB don’t recognise this as a bug.
Thanks. BB
Still there are some users claiming that they don’t have this problem.
That makes it so confusing.
I really want an official statement on this matter.
There is an article:
In this article Steinberg discribes a totally other scenario with this as possible outcome:
(taken from the article)
Shifted MIDI events while recording (events are recorded too late or too early)
If this is true then the OP and all the others like Joel, goodbyenine, Edcubasero and me (hope I didn’t forget someone) are totally wrong and this is a mididriver issue.
So what the hell is going on here??
Please please can a moderator chime in and make an end to this discussion?
Greetz Dylan.
FWIW
When I do the test and use an external apreggiator (not synced by Cubase), to input the MIDI data (to avoid human correction) the outcome is the same as the video. MIDI roughly between 700 - 800 (yes it variates) samples (800 / 44.1 = 18 ms) earlier then audio on a 120BPM project with an ASIO buffer size of 512.
they already chimed in in the other thread. this is Marcus reply:
We don’t have found any misbehavior at this moment. The UAD- Cards and VST Plugins don’t show any issue related to the Midi- Recording.
And Chris just added this link:
https://www.steinberg.net/en/support/knowledgebase_new/show_details/kb_show/midi-issues-on-windows/kb_back/2025.html?tx_p77sbknowledgebase_pi1[keyword_search]=MIDI%20Treiber
So, they didnt even recognize this as something related to Cubase. They didnt bother to ask for specs to the people who suffer from this either. I sincerely doubt they are ever gonna admit its a Cubase bug.
On step input you will find notes reported exactly as Cubase is being given a definitive destination point. Inputting live music in some cases you might find that Cubase will place notes arbitrarily early or late as it cannot read when the input will happen. This is why there is “Priority”, two settings for tighter or looser midi. Why the choice has been limited to two instead of the original four I don’t know.
I would say that, as I play by ear and sometimes Q’ed and sometimes not that I get the problem to some degree but obviously not as bad as the OP. Certainly not enough to stop my show. I expect some timing drifts in pretty much all aspects of recording, analog or digital, but I also expect (and so far it has been) it to be tight enough not to matter in most cases.
As goodbyenine states, it is a tricky problem. I’m not fully convinced either way whether it’s a bug or a design flaw (yes they are different things to the programmer) but also I’m not convinced that any of us, including me, are looking in the right places.
I’m commenting on the SUBJECT at hand and my thinking on it.
I never comment personally on other people like you do. That’s what I consider fight provoking and trolling. Nobody calls anyone else a troll “with all repect”.
Please desist. It’s uncalled for. I don’t want this to degenerate inot a griefmonkey festival.
What I wrote was what I felt at the time and is not a LAW laid down by me. It’s just another viewpoint on the problem in hand. Commenting on others is not a viewpoint that will help the OP.
Though quantisation is stated as not used (a post or two after yours) there may still be a discrepancy there. Quite often dealing with software it’s very easy to see the wrong problem or to actually have more than one problem going on.
If we can nail it here it makes it easier to explain it to Steinberg.
The OP is so far doing a fair job of explaining it so far, I’m attempting to give him some pointers in other areas so he can get some more focus than he already has.
Thanks for the PM and video link Joel. This looks like nothing I experience at all. Way off isn’t it, must be driving you nuts. You expect compensations but that’s just mad.
On a personal bee-in-a-bonnet aside I noticed Kontakt there. I have a nag in the back of my mind about Kontakt as it features in a significant amount of posts with mystery problems. I won’t go on because I don’t want to go off on TOO much of a tangent. Besides I haven’t noticed Kontakt enough on systems working normally. 
As I work over the next few days I’ll see if I can actually get my system to reproduce this somehow and report back to you.
ps: Just a thought. Is that a Template and are their any midi FX on the track that you haven’t noticed? Check the Input Transformer (long shot, unlikely) maybe as if that’s been left on a template it could play harry with data.
It’s just that I’ve been known to chase around a simple solution for days in the past.
Yeah, maybe we shouldn’t see it as a “bug”. It will only bring more confusion and
make developers and support to take a defensive stance.
This is about an improvement, that some producers, composers and
musicians around the world would like to see.
BTW I got some very friendly feedback today. They had forwarded
info to the German office.
That is great! Hopefully we get some feedback now.
Off topic.
@Conman, I think edcubasero has a point considering you a troll.
It’s because your answers really don’t follow the line of thought here. Like CubasePadawan you just want to type long pieces of meaningless text that ’ looks’ intelligent but has nothing to do with the subject. That gives away that you are actually not reading (and because of that) not understanding the issue.
For me that is typical trolling but that is how I see it.
Okay, got that out of my system.
Back on topic 
Just because somebody doesn’t understand what I’m saying doesn’t mean everybody doesn’t understand what I’m saying. 18 years of Cubase and I can go over some peoples’ heads OK?
I try to be positive and try to stay away from being a griefmonkey that just keeps shouting bug with no real end-point to it except to score some sort of points. All you want (from your last post) is an “official statement” about a vague, albeit real, problem whereas I just want to try to fix it. I couldn’t give a toss about getting an “official statement” without knowing what it could possibly could be about.
What I see here is a problem that hasn’t been identified to my certainty or the OPs and I’m trying to get closer to it.
Could be my thinking is wrong but that’s allowed. At least I’m thinking.
And I try to keep away from being impolite enough to comment on others as though I own the place.
THAT is what is called trolling.
And I do have several appreciative PMs from people I have helped. Thank you.
^
Conman, I might be mistaken, but it seems to me that part of the reason for the friction that’s just arisen here is that your posts have seemed to ignore the OP’s notion of what’s going on. So …
- Do you actually agree that a possible - or, perhaps, even a likely - reason for the MIDI notes being recorded early is that they were played early? — played early (probably, without conscious thought) to make their sound come in time with what’s being heard (whether existing tracks or the Cubase click).
– That explanation is what the OP and some others in this thread favour.
- Suppose, for the sake of argument, that that explanation turned out to be correct. Would you then agree that it would be a useful option in Cubase to have the placement of the MIDI notes automatically delayed by however many milliseconds early the performer had to play the notes in order to get the VI’s sound to align with what was being heard? (It seems that Cubase ought to “know” how many milliseconds that would be.)
I said I was done with this thread … but, I cannot help myself from jumping back in.
This must be the case, as it is the only way you can catch up with the beat of what you hear played through Cubase with latency. The playing early includes both midi latency adjustment and audio latency, although the former will be masked by the latter, since it will generally be a smaller value. That is, they are not additive, but parallel latency issues, and playing will simply adjust to the highest, or determinant, source of latency.
This is where I continue to think there is misunderstanding. If you previously altered you playing to make the played instrument remain on the beat as heard … not as seen, if you move the notes forward, i.e., towards the right, and leave everything else in a project as it was, don’t you think the notes must now be heard late, even if they appear to be properly synced to the grid?
Think about this. We all understand tha Cubase uses Plugin Delay Compensation, based upon the highest latency plugin instantiated in a project. How often is that high latency plugin a VSTi? If it is, and you change that out for another instrument that is no longer the highest PCD plugin in the project, your timing of that playback will be different than in the first case.
Cubase, in my view, properly syncs the recording of a VSTi within a specific project. The midi file reflects playing that instrument in that context. Anything you subsequently do to change the projects PDC, increasing it or lowering it, will change the timing of the specific recorded midi track.
How could it possibly be any different?
If an adjustment were made for moving the instantly recorded midi track forward according to PDC of the project this would happen:
-
The specific VSTi would no longer play back in the project as you recorded it … it would be heard late on the beat.
-
If you changed the PDC of the project by removing the high latency plugin or adding a higher one, the track would also no longer be in sync with the audio. (This is an issue in its own right, possibly leading to some thinking the software did something wrong when they change a VSTi and it doesn’t seem to playback the same.)
-
This suggests that you probably should start a project and do all your VSTi at a stage and then render or record by internal summing all your VSTi and be done with it. Now you can be sure any tracks are in sync before you start changing timing with use of plugins in mixing.
-
Finally, as I tried to explain above, none of this has anything to do with the midi timing issues related to variability of when notes are recorded and/ or played back due to midi buffer issues.
Como
No, Como, sorry, I don’t …
As it stands, what the affected users say they’re expeciencing is that, during playback, the VSTi does play too early. To get round this, they manually slide the MIDI data to the right. What the OP wants is an option to have Cubase do the sliding for him, automatically.
This early placement of the MIDI notes is made very clear in the OP’s video, as is the corrective effect of sliding the MIDI to the right. Take another look? (I had to watch it three times before I understood what each stage was demonstrating - perhaps you missed something?)
It seems to me that the only thing left uncertain by that video is the precise time by which the MIDI notes have to be moved. Perhaps it’s more complicated than simply the time it takes from when the key is pressed to when the corresponding sound emerges. But the video does seem to me to demonstrate the need to move the MIDI notes to the right to get them properly aligned with either the click or previously recorded tracks.
Como, I think it doesn’t matter which VST instrument - When a note is on the grid it plays back on the grid. Cubase compensation sees to that all instruments and audio channels plays back where it is placed.
I think Chases explanation was well put.
From seeing the OPs video and answering the part above highlighted. No. What the video shows is midi timing completely out of whack. Nothing to do with what played when. Looks like something is just putting the midi miles out and that just is not happening to many users.
However, other users (the other posters?) who see similar but lesser timing discrepancies might actually be seeing a different problem that might indicate that there may actually be a bug with the timings that is not apparent with purely musical Projects (ie: where the timing does not have to be critically accurate).
So far it doesn’t look to me to be clear where the problem lies, we just know it involves erroneous placing of midi notes.
Cubase hears a note on and places it according to when it arrived (post latency). Now if that note on is erroneously reported by the keyboard generating it or midi filters 
blocking the midi sysex etc. you might find that a confused Cubase could get a bit arbitrary about note positioning.
^
OK …
Though we do know that users say they play ahead of the click in order to get the sound to emerge together with the click.
How about this? …
Suppose someone did another test, where - using the same PC, etc - they recorded in time with the click, but while listening to a sound unaffected by latency - eg using a keyboard instrument that outputs its own sounds.
And, further, suppose it were found - consistently, over several recordings - that (a) when recording using a zero-latency instrumental sound, the MIDI was recorded properly on the beat, but (b) when recording using an instrument with latency, the MIDI was logged too early.
It seems to me that that would provide quite strong evidence that the reason for the MIDI being recorded early was that the performer was anticipating the beat in order to make the sound come in time with the beat.
(While doing the recording using a zero-latency sound, the VSTi ought to be still operational in Cubase, so as to eliminate its presence/absence as part of the cause of any observed effect.)
An all to likely possibility! 
And certainly not the first and inevitably not for the last time.
I’ll try to watch it a couple of more times, too.
However, nothing can convince me that recording midi while playing along with what you hear through Cubase, will not have PDC effect the placement of the recorded midi data … exactly as changes in overall latency does.
Otherwise, why would all who have looked discover that lower latency improves recorded midi timing?
And, early placement of the recorded midi notes is exactly what I am predicting, no?
Como