Parallel Compression - Delay Compensation Error?

[tim_mop1]

Hi all

I'm having major issues trying to set up parallel compression in one of my sessions.

Delay compensation is on. Initially I had my track sent to the main out and used a send to get to a single aux track with my compressor on it. This caused all sorts of phasing with delay compensation both on and off, so I tried routing the track output to a bus, which went into two aux inputs, one with and one without a compressor. Now, this is where I'd expect delay compensation to sort out the problem, but it doesn't! The only way I can make it work properly is to have an identical compressor on the "dry" aux in and bypass it.

UPDATE: as I write this, I've closed and reopened PT and it all works as expected. Has anyone else experienced this?

[Ben Jenssen]

I'm on PT10, but that's how it works here too: turning delay compensation on or off requires that I close and reopen the session for it to take effect. But PT does this automatically.

[Drew Mazurek]

It's always work perfectly here, HD native PCI.

Sorry to hear you're having trouble with it.

[tim_mop1]

Hi all, thanks for your responses so far!

Quick update after some testing:

In this particular session I've been having all sorts of problems with the Delay Compensation engine, but the main occurrence is here:

I have a track (lets say stereo piano), who's output is routed to a bus. I have two aux sends receiving signal from this bus, one with a compressor (CLA76 in this case) and one without. The outputs of the aux channels are routed to the main output. Now, I have an identical send on the comp/dry channels going to another aux send, which has another compressor (VComp in this case), routed to the main output.

If I put the trim plugin on all the aux channels and bypass all other plugins (not make inactive, as the delay must still exist to test), flipping the phase on any of these channels should kill the signal.

This is what I have in my session, and I've made all other tracks inactive for now to test. When that is the case, this all works as expected. As I added in more and more tracks, and my CPU usage got higher, the piano suddenly appeared again, suggesting that the delay compensation had failed.

As it turns out, having the "ignore errors during playback/record" setting switched on means that when there is a CPU spike it tries to carry on and Delay Comp gets all confused. Untick that box and delay compensation works wonderfully, although I'm getting more CPU errors.

[Keith Moore]

Originally Posted by tim_mop1

Hi all, thanks for your responses so far!

Quick update after some testing:

In this particular session I've been having all sorts of problems with the Delay Compensation engine, but the main occurrence is here:

I have a track (lets say stereo piano), who's output is routed to a bus. I have two aux sends receiving signal from this bus, one with a compressor (CLA76 in this case) and one without. The outputs of the aux channels are routed to the main output. Now, I have an identical send on the comp/dry channels going to another aux send, which has another compressor (VComp in this case), routed to the main output.

If I put the trim plugin on all the aux channels and bypass all other plugins (not make inactive, as the delay must still exist to test), flipping the phase on any of these channels should kill the signal.

This is what I have in my session, and I've made all other tracks inactive for now to test. When that is the case, this all works as expected. As I added in more and more tracks, and my CPU usage got higher, the piano suddenly appeared again, suggesting that the delay compensation had failed.

As it turns out, having the "ignore errors during playback/record" setting switched on means that when there is a CPU spike it tries to carry on and Delay Comp gets all confused. Untick that box and delay compensation works wonderfully, although I'm getting more CPU errors.

Having the same issue here. Sending vocals out 1 stereo aux send into 2 stereo aux returns (same input). Not all the time, but eventually it will fall out of phase. I have the "ignore CPU errors" box selected. I'm wondering if that is causing my issue.

[albee1952]

Not sure if this applies, but double-busing(sending to an AUX track, and feeding that AUX track to another AUX track, will usually result in an ADC cluster^&*(. also, if you are not seeing the ADC numbers in your MIX window, go to VIEW>Mix Window Shows, and check Delay Compensation as sometimes you can see numbers that are wrong(and seeing them is the first step to figuring out why and how to fix).

I mention this as I have some sessions that were showing incorrect compensation of over 2000 samples, when there was no plugin showing more than 7 samples. In some cases, it turned out that I had a send on an AUX track which was feeding that same AUX track(albeit with the send fader all the way down). This confused PT and it added 2048 samples for no logical reason

Showing the compensation will also give you red indications if you are using a plugin that has more latency than the ADC function can compensate for(some mastering limiters have several thousand samples of latency, why may not matter on a master track, but can wreak havoc if used in a mix. FWIW, I use sends to feed drums to a stereo AUX for bus compression and have never heard any phasing at all(but the compressors I use there all report 0 latency anyway)

[davemartone]

Originally Posted by albee1952

Not sure if this applies, but double-busing(sending to an AUX track, and feeding that AUX track to another AUX track, will usually result in an ADC cluster^&*(. also, if you are not seeing the ADC numbers in your MIX window, go to VIEW>Mix Window Shows, and check Delay Compensation as sometimes you can see numbers that are wrong(and seeing them is the first step to figuring out why and how to fix).

I mention this as I have some sessions that were showing incorrect compensation of over 2000 samples, when there was no plugin showing more than 7 samples. In some cases, it turned out that I had a send on an AUX track which was feeding that same AUX track(albeit with the send fader all the way down). This confused PT and it added 2048 samples for no logical reason

Showing the compensation will also give you red indications if you are using a plugin that has more latency than the ADC function can compensate for(some mastering limiters have several thousand samples of latency, why may not matter on a master track, but can wreak havoc if used in a mix. FWIW, I use sends to feed drums to a stereo AUX for bus compression and have never heard any phasing at all(but the compressors I use there all report 0 latency anyway)

Quick question.. I have a session set up... which I am getting some phasing going on.

I basically keep Delay Compensation on all the time during tracking/mixing.

When putting a simple stereo delay on an Aux Input track, and routing a mono track to that via a send, when raising the input I notice a definite phasing issue. I tried with any delay, even Avid Delay.

Any ideas what I might be doing wrong?

In the same session I do have a bunch of drums with parallel compression.
For the drums I have made a Drum Master Buss as well as a Parellell Compression Buss for Kick and Snare. Then I have grouped these 2 faders to a VCA Fader. I have no issues with Phasing on these... however as mentioned... phasing happens when just applying a simple delay from another aux track to a mono clip. Any thoughts?

Thanks!

[JFreak]

If you think you have trouble with ADC, it's easy to check by instantiating 100% same plugins for both sides, then bypassing what you don't want to use. If it still sounds wonky, the root cause is somewhere else.

[Stig Eliassen]

Last time I had issues with the ADC engine was with an older version of my Soundtoys plugins, but that doesn't seem to be the problem here.

FWIW...