"Pre-Echo" Offline bounce problem

[off the wall]

Originally Posted by BScout

I don't think anyone has seen this bug before because it is really odd (with tons of uncertainty) to route a stereo channel to a mono bus on a send.

Not really. I do it all the time for cue mixes.

[BScout]

Originally Posted by off the wall

Not really. I do it all the time for cue mixes.

A mono subpath of a stereo bus?
(honest question -- trying to understand the workflow and when this would come up. Stereo to stereo with pan to all left or right I can see or mono legs to mono or mono to stereo but it seems you would have no control by letting Pro Tools mono and send to one channel only the summed signal)

Nevermind. I guess I can see it as a shortcut over doing stereo with all hard pans. You probably wouldn't be running effects on that one leg though (I'm guessing)

[off the wall]

Originally Posted by BScout

A mono subpath of a stereo bus?
(honest question -- trying to understand the workflow and when this would come up. Stereo to stereo with pan to all left or right I can see or mono legs to mono or mono to stereo but it seems you would have no control by letting Pro Tools mono and send to one channel only the summed signal)

Nevermind. I guess I can see it as a shortcut over doing stereo with all hard pans. You probably wouldn't be running effects on that one leg though (I'm guessing)

I would be sending to analog outputs to mono inputs on an Aviom Cue system. Very often there aren't any stereo inputs left mid-session or I don't have time to have someone run to the machine room to switch a pair of mono inputs to a stereo pair.

Pro Tools will just mono sum the stereo feed to the send. No issues.

[BScout]

Originally Posted by off the wall

I would be sending to mono inputs on an Aviom Cue system. Very often there aren't any stereo inputs left mid-session or I don't have time to have someone run to the machine room to switch a pair of mono inputs to a stereo pair.

Pro Tools will just mono sum the stereo feed to the send. No issues.

It sounds like in your setup, the send would be a mono (not a mono subpath of a stereo bus)? Or does that vary? (Only surmising that since the mention of physically re-routing in a machine room.)

This bug appears to be an issue with delaying the whole path equally. I've got three older versions of Pro Tools that I'll try to see if it happened on older versions or if it is something new.

[off the wall]

Originally Posted by BScout

It sounds like in your setup, the send would be a mono (not a mono subpath of a stereo bus)? Or does that vary? (Only surmising that since the mention of physically re-routing in a machine room.)

This bug appears to be an issue with delaying the whole path equally. I've got three older versions of Pro Tools that I'll try to see if it happened on older versions or if it is something new.

Correct, I would be sending to a mono bus. I'm not saying my mono bus use is analogous to the bug mentioned here. I was only replying to your statement that no one would ever send a stereo track to a mono bus.

My cue scenario is only one such common use of a stereo track being sent to a mono bus.

Another would be a mono send from a stereo track to a mono delay.

The point is, it's a valid use case and the delay bug of the OP is serious and should have been addressed by now.

[midnightrambler]

Originally Posted by off the wall

Correct, I would be sending to a mono bus. I'm not saying my mono bus use is analogous to the bug mentioned here. I was only replying to your statement that no one would ever send a stereo track to a mono bus.

My cue scenario is only one such common use of a stereo track being sent to a mono bus.

Another would be a mono send from a stereo track to a mono delay.

The point is, it's a valid use case and the delay bug of the OP is serious and should have been addressed by now.

Yes agreed. I often send to a mono bus if the effect is mono (e.g. spring verb, or whatever), regardless of whether the original track is stereo or mono.

My system is HD Native and didn’t get the issue so that would tie in with the HD-X theory. I have to add that although I like tracking with HD-X, mixing with it is a horrendous experience compared to HD Native (Sidechain compensation notwithstanding).

[frenchman]

Originally Posted by BScout

I don't think anyone has seen this bug before because it is really odd (with tons of uncertainty) to route a stereo channel to a mono bus on a send.

Not odd at all, most reverbs or delay effects are mono input inside, even though they can be used with a stereo input. early reflection on Lexicon for example take the stereo input into account but this is useless in pop/jazz/rock type of context...

Most of my reverbs are on mono aux tracks instantiated as mono/stereo plugins

Thanks for the feedback !
Mark

[frenchman]

Thanks very much for the feedback everybody !!

it *is* probable that HDX is part of the problem, I've done my part, I hope avid solves this quickly !

Best regards
Mark Haliday

[frenchman]

Originally Posted by BScout

I think this might be an HDX thing. For those without issue, were you non-HDX?

I'm seeing the same bug but I think(?) I know why.

First off, the Dverb plugin can be anything (including an EQ or bypassed Dverb) and it'll still do it but then you can clearly see the distance between "clicks".

Second, the Flanger channel is sending a stereo signal into a mono (sub path) bus (Bus 2). If you change that bus to a stereo bus (Bus 1-2), the problem goes away. I think what we are seeing is delay comp only happening on one leg of the bus (bus 2) while bus 1 is staying undelayed. But since we are going out center pan, it ends up looking like the undelayed signal and the delayed signal as two clicks with distance between them (the lack of delay on A1 path preceding the delay comp A2 path)

And the reason I think this is an HDX thing is HDX online uses the DSP mixer but offline uses the system processor. So "native" users are using the same mix engine whether offline or online and it is passing the delay comp info for both paths but HDX users are switching engines where the info isn't getting passed.

Tested the theory and that's what's happening. If you change the source to a stereo (duplicate mono audio file into a stereo track and keep them hard-panned, you can see the right channel delay comp correctly and the left not)

Congrats I think you probably nailed it. Hope this is solved quickly !

[made]

wow, this bug still exists...

Back in the TDM days, I found out that if I only use stereo busses, PT would only use the Stereo Mixer DSP. As soon as you added a mono bus, the Suround Mixer DSP would be added and all your delay compensation would use much more DSP.
To save DSP I configured all my mono busses as Stereo Busses with mono sub-paths...

...until I started to use offline bounce.

Now I'm on HD Native and the bug is gone. It seems that HDX still has the bug.