Charles,

I'm not a protools user (i'm a cubase user), but i have found a lot of the threads on this board very insightful for people who are mixing entire recordings in the computer. I have applied some of your tips and tricks with great results.

Anyways, my question is you have mentioned in your drum setup, that you delay the drum bus by a certain amount of samples to eliminate phase issues with the squash bus. I know all plugins must cause some delay issues, so how do you determine the delay that is inherrent with each plugin?

I'm sure there must be a way to calculate this, I am just not sure how.

Like i said, i use cubase but i have a feeling that there's ways to figure out this delay that is not program specific.

Thanks again for all the insights to mixing, I have grown more in the week of stumbling across this forum and your HDL than i have in months.

bryan

Bryan,

Thank you very much for your compliments. I'm glad I could be of help.

Re latency, PT will actually report the processing time for a plug-in in samples by command-clicking on the fader's volume indicator of the track in question. If Cubase does not have a similar function, the processing delays should be documented somewhere (online, manual, users forum) so that you can calculate it. I also recommend you ask the question of how to calculate the delay @ your users forum. Are there any other Cubase users here who could help?

If that doesn't do it, you can manually calculate the delay by placing one fader out of phase and "sliding" it until the two completely cancel:

• Place all plug-ins on the Squish track in bypass. Not deactivated. You want them to cause the delay without processing the signal.
• Place both the Drums + Squish faders @ 0 dB.
• If you have the Drums fader set-up as suggested in HDL, you should have a Time Adjuster (or Cubase equivalent) plug-in inserted on it.
• Place the Drums fader out-of-phase by selecting the phase button on Time Adjuster.
• Now, with the same audio playing through both the Drums + Squish faders, start from the smallest possible delay setting on Time Adjuster + slowly increase it until the audio completely cancels out.

A third down + dirty solution (and this one is so simple it's like cheating) is to not use a Time Adjuster at all, but to instead place the same compressor (or any matching plug-ins) on both the Drums + Squish faders and bypass the plug-in(s) on the Drums fader (don't deactivate). This way the delay is guaranteed to be identical on both faders, with the only drawback of course being that it uses more processing power.

Hope this helps.

I've been learning about this as well and I just learned about the control+click function in PT (PC based). As I'm clicking on my drum buss and other plug-in effected tracks, the "delay" figure is at 0. Is this correct or is there something else I have to do?

Does that include when routing audio through the internal busses to Cubase's equivalent of Aux Inputs? If so that's great!

Wallace,

Do you have an LE or TDM PT?

BTW-- I added some extra stuff to my first post which you might not have seen earlier.

Charles,

I have LE. I checked digi website and they said :

"Most RTAS plug-ins have zero delay...Practically speaking, Pro Tools LE does NOT have delay compensation, although in many case the plug-in delay will be zero and therefore compensation won't be necessary."

I guess that's the reason?

Thanks for your help!

thanks Charles...

It's always the obvious... flipping phase and nudge till it disappears. Awesome.

I have another question, that is somewhat related.. I have heard of people taking their individual drum tracks and time adjusting them to eliminate the phase shifts between the mics. Something to the effect of taking one mic (eg top snare) and making measurements to each of the other mics and then calculating the time delay of the sound.

Does this make any sense at all to you?

thanks again.
Bryan

ps the new version of cubase does make the claim of adjusting for plugin and bussing latency. I haven't tried the new version out though.

Does anyone knows how much latency is introduced when routing audio thru sends/busses/etc on PT LE?
I just did a test, and an insert D/A/D using 001 converters take 50 samples. I'll do the same test for my RME ADI-8 DS and post back. But I don't know how can I test an AUX delay... if there is any...

None. Bussing to Aux Tracks and even Audio Tracks in PT le does not cause a delay. See my post on the DUC. I also have a test there that you can use.

Shane

I'm on LE too and the funny thing is that the only plug-in latency (according to the mentioned command-click check) happens with the DUY stuff, i.e Valve and Wide show a latency setting of 1. I guess that's peanuts.
LE might not be so bad after all!

Andi

P.S: Charles, I became a DUY user after hearing your apraisal during your last guest spot here, it truly rocks! Since DUY Tape is not available for PTLE, I practically always use DUY Valve (mix setting) on the master bus, it makes a big difference. Like you suggested, I mix 'through' the Valve and add DUY Wide once the mix is more or less finished for that 'ooh!' effect. Thanks for the tip!

Hey, on PT LE 6.x T-Racks doesn't show latency but it puts 64 samples of delay when inserted on a track.

What version of PT LE are u using Shan? I'll do some test now and post back later!!! I'm running LE 6.x (6.2.2)

I'm using 6.1.1 on XP. I replied to your post on the other thread.

Shane

Not all plugins register their latency accurately - as you've seen. I've also not been able to get reliable numbers in many other situations.

As an example, I accurately found the latency for my 192 interface (at 48KHz 24bit) by phase canceling the ITB signal with the same signal going round-trip through the converters. I then did a drum mix setup with two sets of subgroups/aux returns, one with TimeAdjuster set to the appropriate amount, the other going round-trip through the converters for an SSL compressor. Not only did those numbers not work in this situation, but NONE did. There was ALWAYS a comb filter problem, regardless of the numbers. I get the feeling (though untested as of yet) that parallel processing of signals both internal and external (through converters) is not possible. It seems as though I'd have to send the unprocessed drum sub on a round trip through the converters too, so they get the same latency treatment as the SSL subgroup. It wasn't a steady combfilter either. It was swishing around in the high frequencies. Drove me nuts.

This was an experiment to see if things had gotten better since the last time I tried this. Nope. I hope all this phasey mess is cleared up with PT 6.4

If you do it how you mention above it will never work.

The only way to do what you are trying is to copy the drum mix, shift it over by the latent amount, send that to the comp and monitor the return on a rec enabled track.

Than you can mix the originals with your parallel return.

Round trip on my 001 converters is 50 samples. If there isn't a way to compensate this delay... why the Fu*k digi put those analog inserts on the strips?

You can also monitor the return on an Aux Input.

likefire,

In a word, no. Every time I hear this I simply scratch my head wondering what the heck these people are talking about.

For example the kick, snare + toms all show up in the OH's. The snare shows up on the tom tracks + vice-a-versa. The kick + toms show up on the snare track. The snare leaks onto the kick track. If I where to start with the OH's which of the drums (kick, snare or toms) do I line the OH's up with? What about the "phase" of the other two drums? And since the cymbals also bleed into the toms what do I do to get those two tracks to line up? Also, if I were to slide the OH track, now the cymbals would actually be out of time. What about the room mics? Moving them would actually defeat their purpose. The space that is created by them is in part defined by the delay between the close + room mics.

My only guess about why people want to do this is because they can see the waveforms, and they think they are out of phase because they don't line up. No one ever discussed doing this with tape. With out seeing the waveforms it never occurred to anyone, and it wasn't possible anyway. Besides, all of this is unnecessary. The 3-to-1 (3:1) rule should eliminate any possibility of phase problems in most drum recording set-ups. The 3:1 rule states that the distance between two microphones in a multi-mic set-up should be 3 x the distance between each mic and the instruments they're recording to prevent phase cancellations.

If a mic is three inches away from it's drum then just make sure there are no mics within nine inches of it. And if it's only an inch away, no other mic should be within three inches (which there should be little reason for). In a normal set-up the OH mics will be at least 36" away from the kick, 24" from the snare + 12" from the toms. No possibility of phase problems there.

If I use two mics on the kick I will usually line them up. And the same for two on the snare. But moving any other tracks does not correct phase problems IMO it simply creates problems + could make the drums sound smaller by eliminating the size that's created, for example, by the air you get on the kit when you add in the OH's (without moving them).

Hope this helps.

You can do this also, but monitoring it off a rec enabled track allows you to track the drum parallel for a future recall.

I'm not sure we're doing anything differently. I'm assigning drums to a "dummy" bus, then sending them to two separate stereo subgroups via aux sends. One is post fader at unity (so I can mix with the faders), the other is pre fader (so I can have a separate squish mix). As long as I stay in the box with both subgroup returns and compensate for plugin latency, all is well. As soon as I go out of the box with one of the groups (to hit the SSL compressor for instance) that subgroup becomes impossible to properly align. The high frequencies are swishing around like a bad mp3.

I'm quite happy going out of the box for anything I need - that's how I always work. I was just curious (and still am) to see how much of my work methods I can incorporate inside the box with.

Juniorhifi,

Are you offsetting the dummy track by the right amount of samples?

In order to work in the fashion you mention, you must shift it back the right amount of samples.

The timeadjuster plug goes forward but not back.

Your best bet is to make copies of all the drums, shift the copied drums back the right amount of samples, then send that to the stereo comp(individual outs).

On the return they should line up accordingly.

There are no dummy tracks. One set of tracks are assigned to a dummy stereo bus to get them off the stereo bus - so they're essentially going nowhere. Then, using stereo aux sends, I send to two different stereo aux's which are then returned back to the stereo mix. So far so good. One aux is post-fader at unity, so it follows the fader moves. The other is pre-fader, so I can create a sepparate mix that DOESN'T follow the fader. Now one aux return gets TimeAdjuster and the other gets compressed with the plugin du jour. All is well. No phase problems (provided the latency is properly accounted for), except I don't like the plugin du jour, and decide to insert my SSL compressor instead. Now the trouble starts.

No matter how I try, I can not get the two aux returns to align when one is staying internal and the other is going round-trip through the converters. No set of numbers in the TimeAdjuster can make the two line up. The high end always has a comb filter in it. It can be adjusted so it's least offensive, and this could actually be useful in some situation like trying to get that Coldplay "Yellow" snare sound, but really it's unacceptable.

When I'm done mixing this current album project and before I start the next, I'll try a few other approaches to the problem - like sending BOTH aux returns on a round-trip through the converters. Or maybe ProTools 6.4 will be available and will correct the problem. We'll see.

You lost me somewhere.

Basically if i get this right, you want to compress the drums on its own buss with an analog compressor correct?

The reason i wouldn't do it through the aux is that the auxes induce latency on top of the conversion latency.

What's always worked for me is to make copies on different tracks of all the drums you want for the buss comp. Assign those to 2 different outputs, offset them back(the copied drum tracks) by the number of samples induced by the conversion(i forget what it is on the HD 192 something like 91 samples?) and monitor the return on a rec enabled track(that you can record for a recall) or aux input.

Now when you play the track, the return from the buss comp should line up with the original drums.

Voila!!! It works.

Yeah it takes up more tracks, but its the most effective method(until 6.4 i guess).

IMHO a chain of analog devices plus converters cannot be without phase errors. These will be within the specified tolerance (hopefully) suitable to direct processing, but never be null, and parallel processing is to expect trouble. One effect e.g. is dispersion. Conversion rate or sampling freq conversion (e.g. 48k/192k) has an important influence on this. Signals with frequencies higher than a certain threshold will be affected anyway.
Especially dynamic devices like compressors or valve simulators won't have a steady phase offset, so it is near to impossible to model the behavior mathematically and compensate for it.
During the moment a compressor changes its amplification you will have an influence in the phase. That may create the "swishing" sound.

One day there might be a self-learning deconvolutor that can check what is happening and reduce these problems (who of you owns such a device already?). This would be some overkill in digital technology to remove part of the behavior that analog devices are used for anyway.

That's why both the un-compressed and the compressed sub groups are fed from aux sends - they get the same delay (from their respective aux send).

"like" being the opperative word here. It's not consistent, and seems to also vary with sample rate. Like I said, I'll fiddle around with this setup after my current project is done, and post results. Anyone else using this setup/getting different results want to chime in?

A method how to detect latency time has been mentioned in this board.

But if it does not work with an analog compressor or such device, you may want to check what is going on.

Here some complex signals (designed by the author) to stress the system. The curves are tamed, if you test without any EQ, they should keep about their shapes.
Check curve deformation in steady and dynamic areas...

CAUTION!
keep monitoring level _extremely_ low !

Of course, you can search the library for better signals...