Any advice on setting up delay on external instruments in VST Connections for proper midi sync?
External effects have a little pinging option to automatically calibrate the send round trip.
External instruments are said to already have the audio processing delay compensated, so this would leave the midi latency of the midi controller plus midi latency of the instrument when inputing; or, any inherent midi latency from Cubase plus the midi latency of the instrument when sequencing.
While I must assume the midi latency of the instrument is constant, I don’t know if the midi latency of inputting through Cubase using a controller is identical to the midi latency, if any, when sequencing from Cubase. Does someone know?
Is there a way to calculate the value to enter in Delay field, or do you just have to keep making adjustments and ‘listening?’ I thought of an audio recordings of both a VSTi and of any specific external instrument both triggered by the same midi file playing a click track … then taking the two audio files and zooming in on the time line to see the difference in msecs between the transients on the two files. Is this how you do it?
Then just record the instrument to audio & look at the difference between the start of the midi note & it’s audio equivalent.
do you just have to keep making adjustments and ‘listening?’
This worries me a little though as the differences should be a few ms & would be pretty hard to hear unless your ears are very fussy…could it be there’s another problem?? Anyhow this method should show you precisely what any delays may be.
This came to light when I triggered a drum track with my Roland XV5080 and it sounded a little mushy in the track. I changed the midi output to Halion Sonic with a similar dry standard drum patch.
OK, Grim … I read the link and I do have one of the noted possibly problem hardware setups … RME Multiface II. I also have another, an Onyx 800R that ADAT pipes to the RME for line inputs from other external instruments … but the XV5080 main stereo out is direct into the Multiface analog inputs.
I guess I’ll have to go through the archive link to answer a few further questions.
Does “Adjust Record Offset” apply to normal monitoring output … or only when actually recording? I wasn’t hearing the ‘mushiness’ when recording, but when simply monitoring the output of the XV5080 as an external instrument included in the mix and out the control room studio monitors.
While this process will apparently give me true total in and out latency, if Cubase and RME are not reporting it accurately, presumably repeating it once true latency (for that boot, anyway!) is established and then recording the XV5080 output, instead of simply in and out of the interface would provide me info on any additional midi latency.
Thanks. This will be a little project in and of itself … so it may take me a while to run it.
Does “Adjust Record Offset” apply to normal monitoring output … or only when actually recording? I wasn’t hearing the ‘mushiness’ when recording, but when simply monitoring the output of the XV5080 as an external instrument included in the mix and out the control room studio monitors.
No it just inserts recorded audio earlier in the timeline to compensate…The point of correcting this is that you can then go on to measure the midi delay accurately & compensate for it on playback.
While this process will apparently give me true total in and out latency, if Cubase and RME are not reporting it accurately, presumably repeating it once true latency (for that boot, anyway!) is established and then recording the XV5080 output, instead of simply in and out of the interface would provide me info on any additional midi latency.
Exactly…on the 2nd test instead of comparing audio to recorded audio you would compare midi note start to audio.
I do have a sneaking suspicion that what you are feeling or hearing may turn out to be general looseness of cubase/PC midi. I haven’t used external midi since the Atari days but often see complaints of sloppy midi timing.
This does not apply to internal instruments (VSTi)
Yes, this is definately a subtle issue … it doesn’t seem anything like what I was reading people were struggling with in SX3 back in 2005.
But it’s very bad news to hear there is a history of
general looseness of cubase/PC midi
.
I was operating under the naive assumption that if Cubase was ‘rock solidly’ triggering my VSTis, it would be doing the same for my external instruments.
If there is such an issue, I’m going to have to rethink a lot of things.
I do have an E-mu Command Station with a pretty solid sequencer. Maybe I’ll end up having to import my midi to the Command Station and use it to trigger my other instruments recorded into Cubase. But what a hassle!
I am thick sometimes. Thank you in advance, Grim, for your patience.
No it just inserts recorded audio earlier in the timeline to compensate…The point of correcting this is that you can then go on to measure the midi delay accurately & compensate for it on playback.
OK … but originally I wasn’t really asking about “recorded audio.” I was hearing the difference in “mushiness” of the same midi track monitored through Control Room Monitor … once played with a VSTi and then played with the external instrument.
I’m not saying the ‘mushiness’ was necessarily due to looseness of the midi notes triggering the drum … since in both cases I was listening to it in the total mix. It could have sounded ‘mushy’ simply because it was a few sample late, no?
And to keep this all straight in my head … even though I will probably forget and have to come back here and reread it again sometime in the not too distant future! … when I am monitoring through the Control Room Monitor outputs, all delay compensation except any possible inaccurate adjustment of the latencies reported by the interface and that added by midi latency to the external instrument should already be ‘compensated,’ right?
Como
PS It’s not that … with help … I can’t figure all these things out, it’s that sometimes I can’t remember what I figured out well enough to go forward! When I get deep into some of the old threads on Cubase.net with the estimable Grand Masters, I start to think that Cubase is actually some secret project to measure logical cognition and non-linear memory. There’s a lot of 4 standard deviations above the mean folk in those forums.
Alright … I think I’ve finally sorted it all out. Once the loopback test confirms the true latency, I “Adjust Record Latency,” if the test states it’s necessary.
Now I simply use ‘Internal Summing’ to record the midi track and the midi track duplicated in real time, with one track triggered by the VSTi and the other by the external instrument functioning as a VSTi.
Comparing the two recorded audio tracks … actually even without having completed the loopback test … will show me both whether there is an offset in the VSTi recording as opposed to the external instrument recording.
After I figure out that value in msecs, I should then be able to slide the external audio recording in time/ sync with the VSTi recording. I can now simply solo both and see where my transients are hitting. If it ‘meshes,’ I should be good to go.
Of course, this assumes that the attack in the hardware and software synths are pretty close … but even so, if I examined zoomed in sections of both tracks I should be able to see where the transients are lining up. If they line up right, I won’t have to worry about the ‘tightness’ of midi timing to external instruments in Cubase.
Lol…I’m struggling to keep up now!!..this is what I’d written already before your 2 new posts:
Have you tried the “use system timestamp” option in the midi setup…I’m not sure if this can affect playback or only recorded midi again but probably worth trying it on whichever setting it isn’t on at the moment.
The other thing seems to crop up a lot when midi timing is questioned is emulated midi ports…you’ll need to google this as I know nothing…in fact googling I suspect will find you a lot of info on Cubase & midi timing
Otherwise I’d just work through the measuring & correcting of your fixed delays before deciding the problem is any inherent looseness & that you need to change your whole working method…it’s really a lot simpler than it sounds running the loopback test.
& Specifically to answer your last threads…yes sounds like you’ve got it…Hope it works out.
p.s…Do bear in mind I’m far from an expert particularly on the midi side of things, so possibly someone else may pipe in with a far better suggestion for you…but it’s well worth running a loopback test anyway if you do any audio recording.
So … bypassing the loopback test for the moment … I used a midi drum track and a copy of it make by the ‘copy track’ command to trigger both Halion Sonic and the Roland XV5080 setup as an External Instrument in VST Connections.
I then simultaneously recorded each’s output via Internal Summing to separate audio tracks.
The XV5080 audio track was actually 4 msecs earlier than the Halion Sonic’s!!!???
And the transients … except for the offset … all lined up absolutely perfectly across both tracks.
So much for worrying about Cubase’s ‘tightness’ in trigger hardware.
After going through all my tweaking of my external instruments, I had an epiphany (I think): Wow! These settings are only ‘true’ provided that the total plug-in compensation delay (PDC) in C6 doesn’t change!
I am going to assume that the compensation is based upon whichever plug-in requires the longest delay … so.
When adjusting the timing of the external instruments by analyzing transients from matching recorded audio tracks from an external instrument and from a VSTi both recorded from the same midi file, isn’t the difference I am seeing due to PDC?
So if I add or remove a thirsty plug-in, the PDC will change … if it’s the thirstiest, i.e., largest buffered, plug-in in the chain. Correct?
So, I think what I really want to do is figure a way to calculate the PDC. Does C6 report this value somewhere?
Make sure to disable direct monitoring of the interface and not turn on Cubase monitoring or you’ll get a feedback loop.
Honestly, I can’t remember the last time I had to make any correction for driver misreporting and would not even bother testing a new interface now unless I felt like something was out.
… forgot to click “notify me …,” in the remote possibility that someone might actually reply!