Missing delay compensation for side chains - is it unworkable?

[shyko76]

Hi all,

I was just about to fall in love with Pro Tools, when I discovered that it does not have delay compensation for sidechains in any native version. I mean, not even in Ultimate!

This is not intended to be a rant of any kind, but since I make use of sidechains a lot and I don't mean simple bass ducking only - which I guess is not too uncommon with electronic music production - I'm genuinely wondering why this is not really discussed all that often and how you guys keep on working with this serious limitation.

I mean, I've read about people manually nudging clips to make the delay of their source tracks fit, but since this is not a set and forget operation and one would have to adjust the offset everytime I insert another latency inducing plugin, keeping track of the when and where latencies occur seems like an inacceptible PITA to me.

So, how do you work with this? Or is it just an overblown thing to you, that doesn't really matter?

[Downtown_BE]

as far as I know there´s a workaround for that - just use a track without any plugs on it as a source for your SC input.. worked for me

[midnightrambler]

Originally Posted by shyko76

Hi all,

I was just about to fall in love with Pro Tools, when I discovered that it does not have delay compensation for sidechains in any native version. I mean, not even in Ultimate!

This is not intended to be a rant of any kind, but since I make use of sidechains a lot and I don't mean simple bass ducking only - which I guess is not too uncommon with electronic music production - I'm genuinely wondering why this is not really discussed all that often and how you guys keep on working with this serious limitation.

I mean, I've read about people manually nudging clips to make the delay of their source tracks fit, but since this is not a set and forget operation and one would have to adjust the offset everytime I insert another latency inducing plugin, keeping track of the when and where latencies occur seems like an inacceptible PITA to me.

So, how do you work with this? Or is it just an overblown thing to you, that doesn't really matter?

Yeah it’s a real drag.

[Sardi]

Originally Posted by Downtown_BE

as far as I know there´s a workaround for that - just use a track without any plugs on it as a source for your SC input.. worked for me

It’s been a while since I’ve tried, but are you sure that works?

You don’t need to nudge the trigger track at all?


Sent from my iPhone using Tapatalk

[JFreak]

Hi, welcome to the community.

Yes, it is true that currently SC latency compensation feature technically requires HDX hardware, which is why it is missing from all native systems.

I don't see why it couldn't be done on native mixer and would also love it if that feature would be developed very soon. For now, we will just have to wait.

[shyko76]

Thanks everyone! It's a real bummer.

So, what would be the least cost intensive HDX-setup to get? I know it has to be a combination of PCI core-cards plus an interface for I/O-duties.

For example could I just purchase this card and combine it with this interface?

And how about having AAX-DSP and native plugins in the same session? Would the ADC still work in any case?

[JFreak]

Originally Posted by shyko76

For example could I just purchase this card and combine it with this interface?

yes. but it is best buying it as a system so you get all the required licenses

[JFreak]

Originally Posted by shyko76

And how about having AAX-DSP and native plugins in the same session? Would the ADC still work in any case?

One thing you need to understand regarding this question, so bear with me if this gets too nerdy

First of all, the HDX systems have two mixers active, the DSP mixer and the Native mixer, which is the same everyone else is having. Obviously DSP mixer only handles i/o routing and processing of DSP plugins, it does not know of any native processing that is happening elsewhere.

Then again there is the Native mixer. In a purely native system, this is the one handling i/o routing and plugin processing. But in a DSP system, to get the recording latency lowest possible, routing happens in the DSP side of things. So we begin following our sample signal from DSP land of things.

Now, or sample signal enters the card after coming in from the AD converter. This is entry point of a single mono signal, a.k.a. "voice". In a DSP-only system the signal would stay within DSP land, perhaps getting some DSP processing along the way, but it reports itself to delay compensation engine to wait for proper sample to get into the summing mixer and out of the system.

Having native processing in this picture is slightly more complicated, but nothing too much to understand. Somewhere along the way DSP mixer decides it's time to send the signal to Native mixer and expect having it back after XYZ samples of playback buffer. So the signal goes out, comes back in (consuming another voice) and reporting itself to delay compensation engine.

Nothing too much, right? Simple trip to Native land costs one voice (per mono signal) and consumes time as per Native buffer gets into equation. So we already see that full-native system has lower latency compared to hybrid system where you have variable latency from DSP processing and fixed latency from playback buffer.

What if the signal goes from DSP to Native to DSP to Native to DSP...? Nothing more than described above, except now you have a penalty of two extra voices and two times playback buffer. For a mono signal it doesn't sound so bad to consume three voices compared to one, but say you have a 7.1 track, one visit to native land consumes 8 extra voices and two visits would consume 16 extra voices. That would be 16 or 24 voices total, for a single 7.1 track with some native processing. This, among some other points, is why DSP users should keep asking plugin companies to develop DSP versions of their products. And be aware of the DSP/native/DSP/native/DSP pitfall and convert that middle DSP processing to native, which would mean only single penalties and be more bearable.

Okay, so now the signal has gone through all plugin processing... you can follow the signal flow by taking a look at your mix window. It is cleverly laid out so the signal kind of comes in from the top and then goes down to the bottom, which would be the summing mixer in this picture. Between plugin processing and summing mixer are the sends. And in DSP system, all routing always happens within DSP mixer, which always informs the latency compensation engine how many samples need to be compensated and where.

The latency compensation engine simplified is that you have a delay plugin on each track just before summing mixer and just before every send and the information about how many samples of delay is added comes from the DSP mixer. Remember, visiting native land is not much more than adding fixed amount of delay to the signal, the mixer does not care what kind of processing is being done.

And now, ladies and gentlemen, we need to take a look at that one DSP plugin that uses sidechain. Again, simplified, the SC is just input signal used to control the plugin. Some signal that is alien to the signal being processed; kick and bass being the common example. We feed the kick signal into the bass track plugin so to activate the plugin processing as per kick signal -- obviously this alien signal needs to be sample accurate with the audio being processed, which means the SC signal modifies latency compensation math. The simplest scenario, kick having no plugins and bass track only having dynamics plugin taking the SC signal in from kick track... this means the send from kick track to the plugin must introduce at least 1 sample of latency, the number DSP mixer is aware of, and latency compensation must add as many samples of latency to the bass track before plugin processing.. And once the signal goes to plugin for processing -- are you still with me? -- the DSP mixer would know how many samples the plugin processing takes ..OR.. if it's going to take a trip in the native land, which would be the fixed amount of latency specified by playback buffer. Either case, the mixer knows exactly how many samples of latency to compensate.

Long story short, there is no problem mixing DSP and native processing even if you used sidechain processing.

[shyko76]

Wow, such an awesome explanation! I didn't know about the voice penalties at all, but I think, that I understand how the system works much better now.

This, among some other points, is why DSP users should keep asking plugin companies to develop DSP versions of their products.

Yes, I always wondered what the big deal about that was. Now it all makes sense!

Thanks a lot for your time and sharing of expertise!

[musicman691]

Originally Posted by JFreak

yes. but it is best buying it as a system so you get all the required licenses

Is anybody still selling the card and interface and s/w as a combo anymore? Sweetwater doesn't. You can get an HDX card with or without PT but you have to buy the interface separate. Same with Vintage King. Ever since Avid officially unbundled the interfaces and HDX/HD Native pcie cards it seems to be this way (ala carte).