Midi timing suggestion on recorded VST instruments.

I took away this comment - it was misleading sry…

If the problem is in the VSTi’s inherent latencies, then I don’t see how the cure can be in a button to move overall MIDI data. What if I decide to have the track played by an outboard synth after all? All notes will be early, right?

This whole thread is about VST instruments.

*** Outboard midi should not be changed! it’s working good***

My standpoint is it should be handled automatically while recording VST instruments

  • no buttons needed.

enable the compensation when you use softsynths, disable when you use outboard.
So the compensation should not be globally but trackspecific.

This is if the OP is right in his scenario ofcourse. I am still not 100 procent sure but it makes a lot of sence.

Judiging by the info I got, there is a lot going on about this issue. On te S.O.S board, gearslutz, KVR, wel almost every forum where Midi comes along.
I presume that a lot of users are accustomed to move there midi around manually to sync it with the project.
I for one stopped making beats in cycles because of this.
When it worked I looped two bars, and stacked kick, snare hihats etc. Now I do the fitst layer. Stop the sequenser, quantize or line it up and then do the next layer. It would be nice if I could just fool around with drums as I used to.

Greetz Dylan.

When it is consistent with the latency of softsynths…Absolutely +1

Did you send this thread to the mods? I hope they replie on this one.

Greetz Dylan.

You’re outboard synth will play back too early if you’ve recorded the midi through a VST instrument with latency as it works today. That’s why midi and controller data always should be moved later after recording on a VST instruments track. If this would be the case you have the best possibilities of it sounding good when switching the midi track to an outboard synth. One situation where it would seem to work better as it is today though… is if you’re output latency while recording is exactly the same as the latency on the midi outboard synth.

Ed,

I’m not disagreeing with you … but let’s just clarify that there are two types of midi timing problems that overlap.

One is the timing problem related to latency in which all the notes are delayed by the amount of the latency … but other than that, are exactly as played. Shift the track and all is well. I think this is the issue the OP is addressing: why cannot this shifting be done more or less automatically if Cubase is already calculating the PDC?

The other midi timing problem, which you introduce here with the link, is inconsistency of how the notes are recording or drifting note positions within the recorded part. This is a much more serious and painful problem.

This second problem is further complicated by what can be a perceived note misalignment due to the serial nature of midi data transmission … all note data cannot be both sent serially, or one discrete midi message at a time, and also arrive at the sound module in the same instant. Which is what happens when playing chords (polyphony). Cubase addressed this issue with its MIDEX line of midi patch bays, unfortunately no longer produced, and Linear Time Base technology.

So, for the second problem, we have two issues, forgetting latency induced delay: does the sequencer accurately record the midi input and does the sequencer accurately play back the midi data.

Presumably, someone could do the equivalent of a ‘null test’ by sending midi from a hardware sequencer routed through a midi splitter and then simultaneously recorded into Cubase and another purportedly better functioning DAW. Then the original midi file and the two recorded midi files could all be placed side by side in a sequencer and examined for differences. This would resolve the question of timing inaccuracies in recording.

Similarly, a standard file midi file could be loaded into Cubase and recorded into another DAW, and the same file could be rcorded from a 3rd DAW into the one used with Cubase. The files could then again be examined.

I have never taken the time to do all this because it has never been that critical to my work.

But the possibility of demonstrating the second error alleged in Cubase remains, as I’ve outlined above.

Como

That was exactly my point. What I was trying to say, actually - VST instruments should communicate with the host to make the specific delay known to it, so the cure will be in playback, not in the actual musical data.

Amazing! This is the root of the problem… I’ve lived with this for many many years and revisions of cubase. Honestly, When the SX line began, that’s when I noticed the feel was gone. But, in time as with other nuances, you work around them and keep it moving. But to the OP, I agree… :sunglasses:

I think Midi is old and tired…

Are there any plugins at all that operate in this fashion?

I’m not very experienced with VST Instruments, but I know from Wavelab experience that all audio plugins take their own processing delay into account - or, more precisely, Wavelab does.

I won’t comment on every post.

But I’d like to be as bold as to say,
I still believe the simple answer is
written in the first post.

Someone in this thread said this is a
lost battle and that the support team
just answer, keep the latency low.

I think they are willing to consider other
options. I bet they look to improve the
software all the time to make it more
accurate and just “keep the latency
low” - it’s not as sharp as it should be.

Joel,

Any inaccuracy is coming from software and hardware outside of and before Cubase even knows about it, so it is impossible for the DAW to calculate anything when there is nothing to calculate against!

As Como has said already, various companies including Steinberg have at one point or other attempted to address the problem with solutions called “Linear Time Base” or Sample Accurate MIDI from Motu. Even Roland have a solution that aims to help with reproduction of polyphonic data over a serial line.

Any idea that a plug in can compensate for something it knows (and can know) nothing about and feed this information to the mix path is sorely misplaced.

The latency, at least on my machine here and on VSTs , is for the most part, as good as real instruments with the odd, between once a day or week, exception which is expected on anything post Atari and even that had it’s mysteries.
Now I can’t tell exactly how the problem affects you but in my experience most midi timig problems that look like this (most, not all) are to do with stacking things like snare drums. (drums’ll do for now as an extreme example, other things can wait a bit)
Now in the real world stacking snare drums can have it’s problems but with the effects of midi it’s compounded by most of the midi limitations with the exception of a couple of instruments. These can make the problem seem much worse than it really is. Things like strings are, or should be, a lot more forgiving than drums due to their being more ephemeral as a medium so in my case I’d allow quite a lot of movement on these.

I’m trying to get a more focussed handle on what’s happening here as well as consolidating my thinking so please bear with me. I’m trying to ascertain whether the problem is musically related or are we dealing with machine music accuracy here at least in part. To the former a little drift won’t matter but the latter could be a big deal.

Kind of makes me wonder if anyone bothered to read (let alone understood) what the section Windows Timers in the SOS article was about.

I’m sure the number of actual midi problems out there are many. The issue I’m bringing up concerns users with a well working midi. In regards to early placed midi data while recording VST instruments (which is what I’m trying to focus on in the thread) I don’t see your point. Cubase knows what’s going on since the sound is coming out when playing. And there’s something to calculate against: The latency which is a known value to cubase. If it would be the case that you had something connected between the audio output and the speakers, say like an outboard mixer with significant latency. Then Cubase wouldn’t be able to take that in account.

Yes, what Joel says!

Everytime someone chimes in with midi issues that are not a concern to this thread.
Is it so difficult to understand the issue at hand?

Maybe if it’s repeated enough so again:

This is what the OP said in the original post, go to page one to read the whole post but it comes down to this:

When recording on a VST instrument’s track, Cubase
should move the timing of notes forward - equal amount of ms as is the
current output latency. This to give the player and the recorded take justice.



After recording, when looking at the midi editor the midi notes are a bit early

It’s the thing that notes appear early in the editor. Having latency issues in the sence of hitting a key and actually hearing the sound and the time difference between has nothing to do with notes appearing earlier.
When you lay down a chord and that every note comes in serie because that is the way how Midi communicates is all very interesting but has also… Nothing to do with notes appearing earlier in the midi editor.

Hope that we can now stay on topic for real.

Greetz Dylan.

Hi Dylan, no it doesn’t clear up the “issue” and pandering to users who have not understood the underlying causes only promotes a false sense of security and is literally pie in the sky. Besides we are talking about latency, which by virtue is an inexact science since it is predicated on having a properly working system.

Cubase Padawan, why do I get the feeling you can solve this?
That cubase has to move all midi data of the recorded take forward I’m certain of to get closer
an authentic playback, but that the amount of ms should be the same as the total output latency, I’m now late in this thread beginning to be un-certain of. I did some testing and the relation between the midi notes, and what actually
was heard during the take, was differing from note to note, like you were talking about Padawan.
I think that a more precise theory would be this:

Cubase should recognize the time the sound starts playing and place the note on that exact spot. Is that a better way to express what needs to be done for authentic playback?