Does anyone Multi Group Bus Compress in DAWs ?

PaulBrewer

... as opposed to Outdaws , arf arf

Following on from the M.Brauer post does anyone use similar techniques with Group compression?

A cursory scan over some web stuff suggests there may be possible issues with phase or delays even with ADC.

My interest would primarily be in Pro Tools but also Logic.

trackmixstudio

All the time.
I have a bus for kick(s) and Kick trigger and compress the kicks as a unit. Impossible without bussing it first. I have a bus for snare top/bottom and trigger. Same deal as kicks but normally use URS CSP with the mix control on the comp set to parallel compress. Same with toms bus. All these busses then go to a kit master bus which gets a bit of URS CSP FET in parallel mode.
Guitars are usually left uncompressed.
Vocals and BVs and vocal doubles go to a bus and get compressed with Waves SSL bus compressor so when BVs or double vocals come in the overall vocal level is consistent rather than jumping up in level requiring lots of automation.
No problems with ADC. Works very well in logic.
All of the above methods would, of course, be a sh1t storm in PTLE due to lack of compensation. I often hear demos from bands where the kit is phasing all over the place due to compressors etc on busses

jtsuited

I do it a good bit, pretty much in the way brauer describes. the main thing to get right is what you put into each buss. some people just throw all the drums into one, vox/lead lines into another etc.
I find that doesn't work too well.

I like sticking all my percs and subs into a buss with the fairchild 670 on it hitting it pretty hard. Works for the type of music I do.

Have never noticed any phase problems bar the odd kick/bass thing going on.

You can do some real cool stuff if you use the multi bus compression as well as some over the top parallel comping on each buss. Then again it can get very very messy quite easily.

Like everything in mixing though, it's completely down to feel, and that feel only comes with practice imo.

PaulBrewer

It's PT HD I'd be thinking about Michael . Have you any experience in that ?

I was thinking about the parallel compression in Softube's FET comp too which I thought was a cool feature insofar as you're (theoretically at least) going to have the same (if any) delay in the Compressed and Uncompressed signal.

I'll experiment with the URS too.

madtheory

Latency can be a problem when subgrouping in LE alright, depending on plugin used and the buffer setting. Can also be a problem when you load an LE session into HD. I often have to turn on ADC, it's not on by default for imported sessions, which is annoying.

I often buss the whole kit except kik drum through BF1176, or RComp.

DamagedTrax

been para compressing on 1 aux for years now but i'm gonna try it with 3 or 4 and differant flavour comps on each.

had an interesting lecture with ger mcdonnell recenrtly, talking about this very subject.

as far as latency on HD goes, as long as the plug reports the correct latency to PT then its not a problem.

on LE its a differant matter as theres no way to manually compensate for latency on a send.

you can bounce and then compensate with the new audio though.

or use mellowmuse ATA.. not my cuppa tea though. uses up a full stereo buss on the already lacking LE sytem.

anyway, reaper is where i'm at for mixing. (PT for editing)

ZV Yoda

trackmixstudio wrote: »

All the time.
I have a bus for kick(s) and Kick trigger and compress the kicks as a unit. Impossible without bussing it first. I have a bus for snare top/bottom and trigger. Same deal as kicks but normally use URS CSP with the mix control on the comp set to parallel compress. Same with toms bus. All these busses then go to a kit master bus which gets a bit of URS CSP FET in parallel mode.
Guitars are usually left uncompressed.
Vocals and BVs and vocal doubles go to a bus and get compressed with Waves SSL bus compressor so when BVs or double vocals come in the overall vocal level is consistent rather than jumping up in level requiring lots of automation.
No problems with ADC. Works very well in logic.
All of the above methods would, of course, be a sh1t storm in PTLE due to lack of compensation. I often hear demos from bands where the kit is phasing all over the place due to compressors etc on busses

When I was recording acoustic drums (before I switched to vdrums & Superior Drummer 2) in my place, I tried to do exactly what you outlined above... but unfortunately, I'm using PT LE & I felt the full brunt of having no ADC. It took me ages to figure out why my drums had no punch & sounded phasey. I spent ages getting the mic positioning right (using measuring tape etc), minimising room reflections etc. Finally, the penny dropped... no fecking delay compensation in PT, so each of those buss comps were juts adding a little more delay until the kit sounded like it was being played in the local school sports hall.

God bless SD2 is all I can say. I'm now bussing the 6 or 7 x SD2 raw tracks & processing them within PT instead. Holy Mother of Divine Inspiration... it's just sounds so good! I would still like to be able to parallel compress in PT though...

DT… can you elaborate on your comment below… does that get around the latency issues? I might try that approach when processing the SD outputs in PT

DamagedTrax wrote: »

on LE its a differant matter as theres no way to manually compensate for latency on a send.
you can bounce and then compensate with the new audio though.

BTW, is anybody else working away on the “Album in a month” thing?... we’re full steam ahead… to be fair, we started early last week & already had some basic tracks together, but I think we’re on target to get 10 tracks finished by end of Feb. Deadlines are a great man for focusing the mind!

DamagedTrax

basically you render a dry stem of the track that you want to parallel compress and then nudge it back in time to compensate for any additional latency induced by the plugin of your choice.

ie: with a UAD plugin you would nudge it back 1024 samples to compensate for the 1024 that the UAD plug induces.

not ideal, but a work around if you're willing to commit a rough drum mix to stems.

ZV Yoda

DamagedTrax wrote: »

basically you render a dry stem of the track that you want to parallel compress and then nudge it back in time to compensate for any additional latency induced by the plugin of your choice.

ie: with a UAD plugin you would nudge it back 1024 samples to compensate for the 1024 that the UAD plug induces.

not ideal, but a work around if you're willing to commit a rough drum mix to stems.

Ah... I think read about that on the Pro Tools DUC last year... must give it a try & see how it works - thanks!

PaulBrewer

While the TDM plugins seem all good if you drop RTAS plugins into the mix all hell can break loose .... or not.

One was around that is to record a few seconds of click onto every active track and mark it.

If at any stage you have a question on phase/delay nip up to your clicks (with FX muted) and it will be patently clear if anything is amiss .....

Robin Ball

Using NY Comp technique all over! It's magic. Couldn't live without it, don't know how you'd do it in LE though!

DamagedTrax

Robin Ball wrote: »

Using NY Comp technique all over! It's magic. Couldn't live without it, don't know how you'd do it in LE though!

very simple. use a plugin with zero latency. people do it every day.

Robin Ball

Using a plug-in inherently introduces a delay into the audio chain as a penalty for cpu cycle calculations.

If you are using a multiple parallel compressed bus technique then latency is an issue, unless you use the same plugin on both busses, but the point is to use a different on to get a different characteristic.

Delay compensation is a massive help.

fitz

Logic ftw.

jtsuited

fitz wrote: »

Logic ftw.

indeed.

DamagedTrax

Robin Ball wrote: »

Using a plug-in inherently introduces a delay into the audio chain as a penalty for cpu cycle calculations.

If you are using a multiple parallel compressed bus technique then latency is an issue, unless you use the same plugin on both busses, but the point is to use a different on to get a different characteristic.

Delay compensation is a massive help.

nope. every plugin doesnt introduce latency. theres plenty that report zero latency to the host. you just need to figure out what they are.

heres a few off the top of my head.

waves SSL
waves API
waves V series
sonalksis
softube FET (no lookahead)

and when used in zero latency "live mode"
UAD 1176
UAD LA2A
UAD LA3A
UAD 33609se

i can guarantee 100% that these induce no latency. i use them constantly and have no phasing issues with them and all report zero latency to PT le.

its very easy to check in PT. go down to where your dB level read out is and CTRL click the display twice. this will bring you to the latency display.

there are definitly times where incorrect latency is reported to the host. 1 example is using softube FET in lookahead mode but when using a parallel method it becomes very apparent that latency has been introduced even if its only a couple of samples delay. the phasing is obvious.

Robin Ball

I use the SSL bundle and SSL Channel comes up on my system as 1 on the dly window. Hence it has a calculation latency.

The API 560 is coming up as 65

The API 2500 is coming up as 0


There is always a delay, it may be small but you can't deny that the calculations take time, therefore introduce latency. It may be so small it is unnoticed by the ear but it's still there.

You can't deny that Delay Compensation is a beneficial addition....

DamagedTrax

Robin Ball wrote: »

I use the SSL bundle and SSL Channel comes up on my system as 1 on the dly window. Hence it has a calculation latency.

The API 560 is coming up as 65

The API 2500 is coming up as 0


There is always a delay, it may be small but you can't deny that the calculations take time, therefore introduce latency. It may be so small it is unnoticed by the ear but it's still there.

You can't deny that Delay Compensation is a beneficial addition....

i think you're looking for an arguement where there is none.

i stopped using LE for mixing because of the lack of ADC amongst other things so yes i agree it is a deal breaker (for me anyway).

HOWEVER yoda asked about PT le and not being the type of asshole to tell him to get another DAW, i thought i'd answer the question he asked.

when i mentioned the above plugins i should have said all are compressors. i wouldnt use the ssl channel for para comp anyway. so, like i said, the SSL "comp" has zero samples induced.

now it really doesnt matter if it induces a fraction of a sample.. possibly hosts can only distinguish between 0 or 1 and not fractions of. the point is thaat it works. if you're ears cant hear it then you're in the clear (unless you have real bad ears.)

if you want to argue otherwise you may have more look in a science forum.7

personally if it says 0 samples latency and it reports correctly to the host then im happy to use it for parallel compression... im not to bothered about disecting the fractions bewtween samples.

ZV Yoda

Just coming back to this thread... I should have said that the latency issue is only audible when using compressors. On Eqs & reverbs the latency doesn't cause a problem. I'm assuming that's because EQ doesn't take a lot of CPU power anyway... and reverb is a type of delay by default, so latency delays aren’t audible to my ears.

DT, I tried what you suggested... happy days - it works. It is a bit of a PITA though… on balance; I think I’ll prob end up just using the no/low latency plug-ins on the kit. It’s a shame, because some of the IK T-RackS 3 compressors sound great on the kit.

Here's the sound I get using unprocessed SD2 stems. I routed the 6 or 7 outputs into PT LE & then processed using just the Digi supplied Eq & compressors (think I may have also used IK CSR room reverb). I parallel bussed the whole kit via Massey Tape Sat. I'd like the toms to be more ballsy, which is where I was really looking to parallel compress.

http://www.lightningmp3.com/live/file.php?id=21970

Robin Ball

Point taken Trax, It isn't an issue in a real world situation. I have used LE myself and have had issues with Para Comp. I guess I was just using the wrong processor!

DamagedTrax wrote: »

i think you're looking for an arguement where there is none.

i stopped using LE for mixing because of the lack of ADC amongst other things so yes i agree it is a deal breaker (for me anyway).

HOWEVER yoda asked about PT le and not being the type of asshole to tell him to get another DAW, i thought i'd answer the question he asked.

when i mentioned the above plugins i should have said all are compressors. i wouldnt use the ssl channel for para comp anyway. so, like i said, the SSL "comp" has zero samples induced.

now it really doesnt matter if it induces a fraction of a sample.. possibly hosts can only distinguish between 0 or 1 and not fractions of. the point is thaat it works. if you're ears cant hear it then you're in the clear (unless you have real bad ears.)

if you want to argue otherwise you may have more look in a science forum.7

personally if it says 0 samples latency and it reports correctly to the host then im happy to use it for parallel compression... im not to bothered about disecting the fractions bewtween samples.

Obi-Jim

Personally I use both of these methods: (along with DT's, nudging tracks back)

1. Just make sure you put the same plugins on all busses. i.e put compressor on drum bus and on drum comp bus, but disable the drum bus one. (not deactivate, just disable it to blue)

2. On all tracks bring up the delay introduced in the mix window (that DT spoke of). Whatever the longest delay (say 1024 or 2048), you then have to delay each track or bus to that amount, taking into consideration any delay already on a track or bus. Theres a very short delay plugin that comes with pro tools that allows you to delay by samples, looks like the trim plugin.

Also, its worth checking the compensation needed for a lot of plugins with Paul's click method, and just keep a note of it.

DamagedTrax

On all tracks bring up the delay introduced in the mix window (that DT spoke of). Whatever the longest delay (say 1024 or 2048), you then have to delay each track or bus to that amount, taking into consideration any delay already on a track or bus.

see the problem with this is that it wont work for parallel compression.

example

track 1 - 1024 samples delay
aux 1 - 1024 samples delay

by the time that aux 1 finally makes it to the mix bus it has induced 2048 samples delay of which only 1024 can be manually compensated for because no matter how much you adjust the tracks feeding it they will ALWAYS induce the 1024 of the plug on the aux!!!

hence latency inducing plugs wont work for parallel compresion in PT le using the aux method.

Theres a very short delay plugin that comes with pro tools that allows you to delay by samples, looks like the trim plugin.

also a medium one AND a long one. they're called "digi time adjusters"

between them they go from 4 samples up to 8000 odd app.

Obi-Jim

once you set up a master aux for the tracks being sent to be compressed, you can then delay that by the equivalent of the compressor?

DamagedTrax

Obi-Jim wrote: »

once you set up a master aux for the tracks being sent to be compressed, you can then delay that by the equivalent of the compressor?

nope, you're then delaying it twice as much.

you gotta remember this - manual delay compensation means delaying the tracks that have NO delay on them. doesnt really make sense does it!

anyway, the point is to delay everything else to get it in time with the "latency" track.



audio track 1 has 1024 samples
audio track 2 has none (so we add digi adjuster of 1024)

now we send both to aux 1 which has a compressor with 1024 samples

aux 1 now has 2048 samples delay

if we give all the other auxs the same latency then anything we send to our parallel is going to have 2048 samples delay before hitting the master

this is normally ok with a zero latency plug because it hits the master at the same time as the first lot of auxes.

if we put a latency plug in we now have 3072 on our parallel aux and if we go back to our sent auxes to try compensate ANY latency we add will also be sent to our parallel bus increasing the latency!!!

its a bitch huh? :eek:

Obi-Jim

umm, i'm not sure what you mean by "all the other aux's"? what are these auxs routed to?

This is what i mean:

Audio 1- with a plugin of 1024 delay.
Send to "(Bus 1) gtr comp"
Output to "(Bus 2) Gtrs"

(aux 1)Gtrs - input -bus 2
Output - Mix
insert time adjuster of 1024
(aux 2)gtr comp - input - bus 1
Output - Mix
insert comp of 1024 delay

Aux 1 is acting as original dry gtr
Aux 2 is the compressed signal

Total delay of 2048 on all tracks going to mix.
Make sure any other tracks going to your Mix master track are delayed by 2048 samples.

Theres nothing strange going on there that i can see?

DamagedTrax

sorry. im talking bout going 2 or 3 auxes deep. you're method is really only for 1 deep. try sending from your aux into another aux ( with latency on it) and see how messy it gets

i think i was thinking bout it too hard.. with only one group of auxes yeah its possible.

Obi-Jim

yea fair enough, if you had that much going on, absolutely it'd get a bit messy.

This can be helpful for simple but good parallel compression on drums, gtrs, vocals etc...

If it's simple enough stuff, I'd usually just output Audio 1 to Bus 1, then have both auxs input bus 1. Rather than use an extra bus for the send. Just have it all time aligned then.