Have you ever used GainMatch for delay compensation?
Not that I come to promote the brand, however I saw a video in which they use this plugin to adjust the delay compensation of external effects (in another DAW)
Video:
I was surprised by the accuracy, so I gave myself the task to try it in Cubase, since the delay compensation in external plugins, is never very accurate to say… for this to work you must make a sandwich, that is to say… place a GainMatch insert as it is, then the external plugin of our effect, then another GainMatch, in this we change the mode to After, turn on the green speaker button click on detect delay and vuala… in my case I put the GainMatch ms in 0.000, since in my equipment is the best configuration, and the delay disappeared!
it does its job very well… my question is; why the same external plugin native to Cubase, fails to be accurate and there is always a little delay…?
This looks like something I should try. However, after install in the prescribed way, as I open Wave Lab Pro 11 it tells me the file is corrupted. As I open Cubase, even though it is in the correct VST3 folder, it does not show up in Cubase. Seems a bogus product.
Cubase External FX Delay Compensation is sample accurate. Either your interface drivers are not reporting latency correctly or you have misinterpreted what delay compensation is and when it should be adjusted.
By the way… do you have external FX? like a compressor? an EQ?.. or some kind of processor? if so… I would like to see what you are affirming, because if you mention it is for a reason and by having a perfect delay compensation that you can match with what you hear in cubase and what you hear coming out from the mixer of your audio interface…So everyone here would really appreciate it if you could leave us a video showing how you compensate so accurate as you say.
The simple answer is, I don’t do any compensation. Cubase does it all. Cubase knows the input and output latency of your AD/DA.
Yes, I have an array of analog components. There is no delay worth measuring in short runs of cable/analog circuits. It’s essentially, “instantaneous” electricity. An analog compressor or EQ doesn’t have latency.
If we are talking about Digital Outboard equipment, ie, you are going analog out, to analog in on a piece of gear that is then converting the signal to digital for processing then back to analog… this piece of gear will have its own AD/DA and processing latency - This is what you use the ‘Ping’ for in the External FX. Because this piece of gear is not communicating its specifications to Cubase.
Try it yourself, patch your DA right back into the AD and playback/record a test. If there’s no latency in the recorded result, then there would be no latency using an analog compressor or EQ.
If there is latency, you’ve either tweaked something in your settings you should undo, your interface is not reporting correctly, or I’ve heard speculation an improperly coded VST plugin might not report latency correctly.
Amazing that you don’t have delay in your system but then I wonder why there exist a button called “measure delay” in Steinberg’s “external Plug-ins” (designed for analog gear), and of course, besides the parameter that you can manually adjust… however I will try what you mention… but honestly I don’t think is about wrong tweaked, as I didn’t tweaked anything else than connect the gear in cubase and physically… so if you ask me, is a basic config.
I have delay in my system, it is just accounted for. Go look in your Studio Setup, it lists all the latency amounts when you selected a device. Cubase already knows the latency, why would you need to do anything?
I explained the intended use for ‘Measure Delay’ as ‘Ping’
If you set the maximum amount of latency in a project, highest buffer, etc, etc so that there was 1 second of latency, and then had a drummer play to the track… The drummer isn’t going to be 1 second off the grid, because Cubase knows there is one second of playback latency and it also knows the input latency… Thus, the recording of the drummer (if the drummer is good/not on drugs) sounds and appears as it should.
It’s no different than with analog gear. Cubase is self aware of the playback and output latency as well as the input.
The above only becomes a problem if you are using Cubase for live monitoring. But irrelevant to what we’re discussing here.
I am and have been using PCIe AES card connected to my Interface instead of USB… so i don’t know, maybe this is different with USB interfaces/drivers.
Cubase will automatically compensate for the latency in your ASIO system. The problem that I have is that I use ADAT with lightpipe connected to external converters which transfer audio faster than the reported delay of my system, so I will insert a delay plugin (Voxengo Sound Delay set to 64 samples) before any external devices hooked up to those external converters.
I find this all very interesting. Unfortunately, my MOTU M4 is not able to create a roundtrip ping number in Cubase (using the Ext Efx loop) but it can do this in WL Pro, the number in WL is 9.8ms while being routed, via USB C, out of the M4 to a Manley Opto Comp and back to the input of the M4.
I did talk to Steinberg about this conversation here, the idea that this latency number is unimportant. Their response was to confirm that this was a Cubase bug and that eventually they would fix it with an update. (An update that is on hold while C12 is launched, apparently.)
So the round trip ping number when used in the Ext Efx loop should exist and it is important to Steinberg. If they are capable of creating Cubase I think they know what they are talking about, right?
Is it a bug in Cubase, or is it a bug in WL? or is it an ASIO bug with some devices?
Have you tried simply routing a test signal out an ExtFX Insert, out your DA and straight back into a AD channel and recording it to see if it doesn’t sync?
I simply draw in an audio event, zoom in to sample level and draw in a few sample bumps, insert an extFX on a group, the audio events track gets sent to that group, extFX DA to AD set, set up a record audio track and set the input to the groups output.
For me, the recording always lines up with the original sample bumps.
If the ping is resulting in 0 - then you could presume Cubase has compensated for latency no? Perhaps WL isn’t, or, is your hardware setup/chain at all different with WL?
No, same chain in either program. The mind rather balks here to think that Steinberg Support is completely lost regarding delay compensation while using the Ext Efx loop. Given the options, I have to go with Steiny here, sorry. Post some pics of your wave files. Who knows, you might cause Steinberg to remove the the ping option in Cubase.
the ping option doesn’t need to be removed regardless, as it is intended for devices that have their own AD/DA and processing time which isn’t being reported to Cubase - like a Weiss Compressor, or an Eventide effects unit.
You do my test, and post pics. I’ve already done the test, and my eyes aren’t lying to me.
Think about it, why would we need to ping analog gear? It has no latency. Why would we need to ping the DA->AD path when Cubase already knows both latencies. We should not want to have to use the ping in such cases.
My suspicion is that WL handles this differently because it is mastering software and decided users should specify this themselves because it’s not uncommon for Mastering engineers to use different AD from their DA, as well as using a variety of digital outboard.
Cubase automatically compensates for the delay , it reports back what the time delay is and compensates , my SPL’s normally come back at about 46ms and once you click on the insert you can hear the whole song being compensated for if you activate while running , ive never had an issue with external compensation
Have you confirmed with Steinberg that the bug is coming from Steinberg or is it still a guess?
The question is because I also have a MOTU 828 X, and it struck me that you have similar problems. … Have you opened a ticket at MOTU to rule out that it could come from the drivers?
Yes, I created a ticket with Steinberg. They confirmed the problem and said they would try to find a fix, even suggesting that it would be for C11. However, a month later nothing has happened and I see now that all Steinberg attentions are on C12 at this point.
BUT…regarding this, I did contact Steinberg (via my support ticket) and asked where they were with this. The answer was vague, to the point that I don’t believe that there will be a resolve to this issue. It was a basic blah blah nothing said reply. ??
As to Motu and their company’s involvement, yes, I contacted their support team about this. They watched a video I sent, and then sent me their video that shows the Motu performing a loop procedure correctly while using their Digital Performer software. Their response was to say that Steinberg has not accommodated the Motu product: that the problem I’m having is a Steinberg problem.
At this point one begins to wonder - both in Motu’s and Steinberg’s case - if it’s such a good thing to have a company selling both a DAW program and an interface? Imagine if Waves/iZotope/etc. started making an interface that was the only DAW you could use their plugins with?
And btw, I updated the latest Motu driver and firmware (dated December 15, 2021) yesterday and nothing has changed the Steinberg problem I’m having.
You’re not helping anyone here or yourself by not doing a simple test.
I have a Lynx Aurora, everything as far as I have tested, is automatically delay compensated. The only time I use ‘Measure Ping’ is when I am using digital outboard FX that have their own latency.
What exactly is “Motu performing a loop procedure”? What is a loop procedure? Are we talking about a DA->AD re-recording test that results in perfect alignment without any ‘Ping’ measurement? Or are we talking about a ‘Ping’ measurement that finds the latency?
I’m going to lean against MOTU on this one - if an AD/DA Interface manufacturer is serious about their products being able to be used by anyone to universal standard - they aren’t going to only use their own DAW to test the products.
GexiCam, Motu’s loop test was their way of duplicating what Cubase and WL accomplish in the Ext Efx connection (which is a loop). Describing their process, they patched a mono track out of their DAW (DP) via the M4 CH3 Out, into an external analog compressor, and then back into the CH3 In. Using Digital Performer (DP) the resultant delay was 10ms or close to it as I recall.
Since you’re here, and I do appreciate this, I wanted to ask you something? When you say that analog gear doesn’t create a delay to the audio that’s an interesting comment, and, although I think it must create some measurable delay, I agree it would be small, maybe 2ms but I have no tools to measure this accurately. However, this is not the source of the greatest delay to the signal, which I’m sure you know is the DAC/ADC chip in the interface. Which is to say, and I’m sure you would agree, that the signal sent out and back does have a delay to it.
OK. So, does Cubase compensate for this delay naturally, and therefore, the pinging of the in/out signal within the loop become unnecessary? It seems I will eventually have to try your experiment because Steinberg is not resolving my concern, but not today. What I will still ask you is that doesn’t it seem odd, (if what you say is correct), that Steinberg (and every other DAW software product) has created a ping process in their Exit/Return loop of a prerecorded track? Are these software developers going to all this trouble because they have nothing better to do? Why do you think that Steinberg agreed that this is a bug when it is not?
Okay, so this doesn’t really negate the test because it’s possible Cubase auto compensates and MOTU DP does not.
The only way to verify that is to do the test.
Analog gear, or more specifically, electricity does have a travel latency but it’s somewhere around 1 nano second per foot. It wouldn’t even make a discernible difference in phase that the human ear could hear.
There’s 1000 nanoseconds in a microsecond, and 1,000,000 microseconds in a second. To put that in perspective, an AD/DA Converter at 192khz sample rate, is specifying, 192,000 samples are being taken every second.
I’ve explained a number of times what the Measure Delay/Ping is for. A Lexicon PCM41 delay, is and old vintage digital 19" 1u rack delay. Because it is digital, it has to convert AD (analog to digital), run its DSP processing, and then convert Digital back to Analog (DA). This means this hardware has its own base latency that Cubase does not know about, and thus, has not taken into account for its compensation… Unlike your interface AD/DA which communicates to Cubase through drivers and ASIO protocol.
That is what the ping is for. I use it all the time, for a variety of digital hardware.
