Hmmm, this is very interesting. You and Conman are actually at odds. Conman says Cubase is not designed for recording VSTi’s live and to go buy LIVE if you don’t like it. Yet, you say there is a solution with a simple click. Come on guys, let’s see the two of you go at it.
The trolling tool’s answer doesn’t work. System timestamp doesn’t solve it at all.
If Steinberg support don’t have the answers, he certainly doesn’t.
Just looking through the plug-in reference manual and it hit me…
On page 15, niles posted a method to use the logical editor to fix this MIDI VST recording issue.
Could this solution not be applied to the transformer MIDI plugin for realtime processing? 
First time: Set latency, save preset.
Subsequent times: Load preset.
Boom 
Problem solved.
That’s correct. We don’t agree here. You lot STILL don’t get what the OPs doing. Here goes. THIRD time.
Aside from recording the “thump” for reference as AUDIO
A: He’s recording a VSTi via MIDI. So far so good from the screenshot he gets exactly how recording a VSTi should be.
BUT
B: He’s also recording an AUDIO FROM the VSTi.
ie: HEs NOT recording the audio the VSTi is BEING recorded by Cubase AFTER his action at A. The VSTi recording is generated first and then it is re-recorded to AUDIO.
It’s taking a full circuit again through the computer to get there. This is NOT a commonly performed action by DAW users. As for most purposes it’s a useless exercise. ie: For most people recording the VSTi is enough. If they need to render to audio they usually do that later and safely.
From the screenshot I’m not at all sure the same input is being performed in Live. Could be.
In this case the solution (and I’ll have to look myself) would/could be to alter the AUDIO recording offset in Preferences.
ok, after the third time I think I see your point now. Sorry, I thought the VSTi had some kind of latency. Now I understand that he is recording audio FROM the VSTi. It is being generated first and re-recorded. Now I understand. Thanks!
Cheers man. thanks.
I think we are coming full circle.
For recorded audio from a VSTi to be on the ‘beat’ with the project timeline beat markers, the midi generating it must be before the beat. The ‘earliness’ of the midi must be roughly a reflection of the PDC of the total project, i.e., subject to the delay of the plugin, including possibly the VSTi itself, requiring the greatest delay for compensation.
Como
Has nothing to do with Sys Timestamp (the OP’s issue, that is). 
I know full well what the issue is. Like I said, a simple setting cures it. Even says so in the manual.
Nope
By any chance are you talking about “Constrain Delay Compensation” and “Delay Compensation Threshold”?
It’s a “one-click” solution and they haven’t yet been mentioned in this thread (I searched).
Sorry and thanks?!
Look at the video again…
The realtime audiotrack is just to show that the midi is coming in early.
In fact, after the ‘full circle’ the audio is perfect in sync!!
The culprit lies with the MIDI information, after the recording it’s shifted "back’in time.
So to emphasize again: The audio recording has nothing to do with the problem!!!
Or: Conman is a big **** Troll, trying to hijack and sabotage this thread with presposterous nonsens
Or Conman is not a trol but cannot understand the issue after 17 pages.
Can a moderator please please lock this thread, it’s full of rubbish and stupid debats.
Can then the OP please start another and hopefully get a serious thread without Conman and co?
Regards Dylan
Regards Dylan.
I looked at the OP’s video.
Constrain delay compensation was off.
Could this affect the MIDI note placement (by overcomensating)?
Would it correct the issue with it turned on?
No.
Alright then, that theory out the window.
There is no problem! It’s a suggestion for an option to place the MIDI, relative to the output latency of the VSTi.
Would programming your workaround (on page 15) into the transformer plugin work?
I mean: would it make your workaround automatic?
Fait enough.
It does the job to a certain extend.
It’s not fully automatic because we can’t automatically retreive the overall (or plugin) playback latency information into the logical editor. So we have to manually submit the amount of samples the playback has to be delayed.
After that’s done, it works. But mind the “known issues”
So in short. Yes it works, but not flawless.
I posted this back on page 17.
I assumed no automatic latency reporting, so I compromised with presets (to make subsequent uses faster).
Would also have to be fine tuned as well, I guess.
Known issues?