External FX producing the opposite of latency

I’m not sure how to describe this other than the opposite of latency or negative latency, but since I’ve started reamping. I’v been using cubase’s “External FX” feature to do this.

Even the compensating for the 2ms of latency the system detects (via cabled output routed to input as a test) seems to result in the recorded result ending up BEFORE the time on the grid it was before.

A great test I did was using clicks via GrooveAgent aligned to the grid, and they consistently seemed to arrive 62ms before
each grid line.

Is there some feature I’ve missed, or is this a common problem?
Untitled-1.jpg

Are you routing using external effects from the VST Connections dialog (page 30 in the operations manaul)?

Using VST Connections will sync your external effects ‘round trip’ time to the plugin delay compensation Cubase is calculating internally.

Como

Used to be fairly common. Fix for you might be to “Enable sytem timestamp” in the Devices Setup. Could be dependant on the sort of input used and the way it times it’s midi data packages.

@ Como - The delay compensation feature currently can’t fix the problem because this isnt a delay. it’s the opposite of a delay and the feature only includes positive values. IF the feature included positive and negative values then maybe I could get it aligned.

MIDI time stamp doesn’t seem to help the audio either sadly.

Thanks anyway guys

For Re Amping I just set an output buss to the reamp box and just a plain old ordinary input and record, works well.

@split - ah… this method gives me the opposite problem. latency in the region of 3ms (which isn’t terrible), but I just wish i could get it where I want it latency free, preferably using the FX method

Is that 3ms with a loop through, ie lead straight out and back in ? (not using external FX method)

For what I do, which is to re-amp guitar parts with a amp and mics (mainly) 3ms would be irrelevant!

yes, a loop through, I realise with a microphone and speaker cab there will be time added based on the distance too

Ah, i see. I suppose 3ms isn’t too bad, I do find myself dragging them around though if they’re slightly out haha.

With the Ext FX method (if it ever worked properly for me), I wouldn’t need to load up the settings in the VST connections each time for existing projects…

I suppose, thing is if I close my eyes and I cant hear anything wrong then it’s right… Right?

Trouble is, 3ms or so can look like a big amount when zoomed in but with guitar re-amping it’s really nothing to be concerned about. Well at least thats what I tell myself :laughing:

I do get your point haha - I suppose it’s only over 11ms where the human ear can really notice the difference audibly

I’m away from my DAW for the weekend … but I thought it could take positive or negative values. Anyway I thought the ping function was simply to identify the external round trip … regardless of whether it was longer or shorter than the PDC, and then once Cubase knew that value from external effects it could sync things.

PDC is, I believe, constantly changing depending upon what other vst is running in the host.
Como

Would Cubase not just need to set the overall delay to the delay of the channel or chain with the biggest sample delay, then adjust all other channels to suite and stay like that untill any other additions were added by the user?

Has the OP maybe got constrain delay compensation enabled? as one would not expect a -ve delay value on a round trip to the outside world and back!

sadly it only seems to deliver the signal early, even with a full project… something’s wrong with the internal compensation… also you can’t run external FX with “constrain delay compensation” turned on, it switches off things like dynamic processors and… this too.

I assumed it would have the ability to automatically compensate for however many plugins were running and an increase in overall delay, but so far I’ve had no luck

Thanks

Alsdair …

This is driving me a little batty. Please describe exactly how you are routing this in VST Connections.

You haven’t said so, but are you sure you are routing through the ‘External FX’ tab?

As I said … or tried to … almost all external routing is going to add some latency. Even if your return is coming back early into Cubase, that doesn’t mean there wasn’t delay, just that it was less than the rest of the delay introducted by plugins, etc. Once you set up your External FX bus, there is a drop down menu (PC right click on the name of the bus) and an option is “Check User Delay.” This gives Cubase the value of the particular latency of your external fx setup. If you haven’t done this (and of course not routed this wasy) Cubase may not have the required values to enter the signal delay into the PDC equation.

If worse comes to worse and the 2ms is constant … just slap a delay on the return channel in the mixer.

Como

@Como Balia:

Yes I’ve been using the External FX tab, however if you ask it to “check user delay”, it will sit at around 2ms and still deliver the signal early, I think cubase is incapable of solving this the correct way.

I may indeed have to resort to the delay on the return sadly! quite annoying…

Devices setup / Midi ? “Use system timestamp.”

The helpfile (from the help button, not the manual) explains all.
What Soundcard are you using?

My latency is about 5 in and 6 out. Latency is relevant to input monitoring on the fly, 3ms should be adequate as the industry has thrived on much poorer latency for many decades now.

I should be worried. I did hear a singer at a live gig soundcheck the other day complaining that the latency thru his pa was a bit much and he was wondering what it (the latency) was. That’s the first time I’ve heard any muso playing live complain about latency. I hope it doesn’t get fashionable. I think I did see a drum stick hit him round the back of the head about 5ms behind the beat later on. :mrgreen:

My problem is not 2ms… my problem is all the audio arriving 63 milliseconds early! arrgh. it seems like there’s no “proper” solution to this either

hm. steinberg have offered no helpful solutions yet. It was recommended that I deactivate “Adjust for Record Latency”, or change the Record Shift value, both of which would have extremely negative impacts on ordinary recording. for anything other than External FX, I seem to get around +1.5ms of delay… for some reason I get -63ms for External FX

What audio interface are you using?

FWIW - I reamp quite a bit and never have problems. I do not use the “External FX” feature to do this - I just set up a mono output buss to one of my D/A channels and route the Guitar DI track to it. I then track the amp as I would normally and everything is perfectly synced up (with the exception of the slight delay introduced by the distance between the mic and speaker etc).

I do use the External FX feature to insert hardware compressor’s and EQ’s almost constantly (and without issues). The round-trip delay for my D/A/D chain is typically around 1.86 ms @ 44.1 Khz. The delay that is compensated for is purely from the D/A and A/D converter latency - if your audio interface is not reporting the correct values for it’s true latency, things will not work as they should.

Last, how exactly are you exporting the audio out and back into the project since you appear to be using the External FX for this task? I will argue that my method of setting up a mono buss output to route the DI track out to the D/A -> amp makes more sense, but you should be able to use the External FX feature and have the tracks line up properly. Also, just to clarify - you are reamping guitar/bass DI tracks to a real amplifier and then recording a mic’d track?

Echo audiofire pre8. Pretty good interfaces with reasonable drivers.

Yes, reamping with amp and mic and reamping box. It just arrives early using ext fx, but normally via the mono out method…

for testing the fx send and recording the result, I ran a cable from one of my mono outputs back into an input using a balanced TRS jack to jack cable, and got -63ms recording beats previously lined up to the bars onscreen

Very strange indeed