Quantcast
Does ADC work? - Gearspace.com
The No.1 Website for Pro Audio
Does ADC work?
Old 25th September 2012
  #1
Lives for gear
 
🎧 15 years
Does ADC work?

I'm wondering what the general consensus is. I'm under the impression that most people regularly run in to limitations with it.

I recently had some problems with it that forced me to spend time really learning how it works and adding up every piece of every signal path to find where the problem is. Once I could see where the problems were and understood how it works, I was able to change my routing to get the exact same processing results, but without the comb filtering caused by mismatched latency.

At this point I believe that it works properly, but I want to test my understanding of it to see if I just made a lucky adjustment or if I've really gotten to understand it properly.

Maybe I'm just behind from being an analog holdout and it's no longer problematic, but if people are still having problems I'd like to see if I can figure out a way to make it work based on what I just learned.
Old 25th September 2012
  #2
Lives for gear
 
loujudson's Avatar
 
2 Reviews written
🎧 10 years
What Daw?
Old 25th September 2012
  #3
Founder
 
Jules's Avatar
What daw / interface combo?
Old 25th September 2012
  #4
Lives for gear
 
🎧 15 years
ProTools.
Old 25th September 2012 | Show parent
  #5
Lives for gear
 
loujudson's Avatar
 
2 Reviews written
🎧 10 years
Quote:
Originally Posted by Mike Caffrey ➑️
ProTools.
What Jules asked - interface? PT version? It all works just fine for me with PT9.0.3 and Black Lion 002R...
Old 25th September 2012
  #6
Lives for gear
 
🎧 15 years
How does the interface make a difference?
Old 25th September 2012
  #7
Lives for gear
 
🎧 15 years
I'm going to assume this means there aren't no or next to no issues with ADC in any of the versions or it would need such specifics to identify them.

I wonder why I had such an impression that people were getting combfiltering with things beyond basic routing.
Old 25th September 2012
  #8
Lives for gear
 
loujudson's Avatar
 
2 Reviews written
🎧 10 years
You may have had that impression from PT8 which did not have compensation, or people who use external hardware as inserts - that need hardware compensation as well as ADC.

Curious why you won't say what you are using for interface...
Old 26th September 2012 | Show parent
  #9
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by loujudson ➑️
You may have had that impression from PT8 which did not have compensation, or people who use external hardware as inserts - that need hardware compensation as well as ADC.

Curious why you won't say what you are using for interface...
ProTools 8 had compensation.

Because the interface isn't relevant. I'm using RADAR. Happy now? I'm curious why you care.
Old 26th September 2012
  #10
Lives for gear
 
loujudson's Avatar
 
2 Reviews written
🎧 10 years
I *don't* care. We were just trying to answer your question. But different DAWs work differently, so saying people say ADC doesn't wortk is specious and irrelevant without specifying the gear!

So do you use PT with Radar? uh huh, sure.
Old 26th September 2012 | Show parent
  #11
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by loujudson ➑️
I *don't* care. We were just trying to answer your question. But different DAWs work differently, so saying people say ADC doesn't wortk is specious and irrelevant without specifying the gear!

So do you use PT with Radar? uh huh, sure.
Right, but ADC is software, not hardware.


So now what, I have to prove to you that I use ProTools with RADAR?


Regardless, my question has been answered. There are no issues with ADC because if there were the answer to the original question would have been to direct me to the ones that have problems.

I'm just behind because I haven't had a reason to really dig into how it works because the complex part of my bussing has been OTB until recently.
Old 26th September 2012 | Show parent
  #12
Moderator
 
psycho_monkey's Avatar
 
🎧 15 years
Quote:
Originally Posted by loujudson ➑️
I *don't* care. We were just trying to answer your question. But different DAWs work differently, so saying people say ADC doesn't wortk is specious and irrelevant without specifying the gear!

So do you use PT with Radar? uh huh, sure.
why the suspicion? you do realise who you're talking to?!

You can totally use PT with Radar - either tracking to Radar then transferring, or more usually using the Radar converters and going digitally into PT.

you do have a point in some cases - hardware inserts won't be properly sample accurate with non-avid converters.

Shouldn't affect ITB ADC though.

not sure why the comment about PT8 not having delay compensation - we're not talking LE here!
Old 26th September 2012
  #13
Lives for gear
 
🎧 15 years
I ran into a lot of ADC issues, especially noticeable as you say with parallel stuff on auxes in PTHD 8. In 10 HD|N I haven't had any problems at all. The only thing bugging me in 10 is that it won't always shift the compensation to audio tracks when it is possible to do so. Making it a bit of a hassle to monitor through your session.
Old 26th September 2012
  #14
Lives for gear
 
jumpnyc's Avatar
 
🎧 15 years
I find significant issues with ADC when using a combination of Tdm and rtas plugins on a track. Latency can be up to 6-8 frames with adc engaged.
Old 26th September 2012
  #15
Lives for gear
 
synthoid's Avatar
 
🎧 15 years
Oh, there are definitely issues with ADC using non-Avid interfaces for sends/returns. I'm afraid I don't know enough about PT versions to say whether these problems are cleaned up now, but in earlier versions of PT, I saw myself that using the Avid interfaces, return tracks were sample-accurate in alignment, but were off by a few samples using other converters. I think one simple issue is that PT may not be cognizant of the actual sample delay of various interfaces/converters.

-synthoid
Old 27th September 2012 | Show parent
  #16
Moderator
 
psycho_monkey's Avatar
 
🎧 15 years
Quote:
Originally Posted by synthoid ➑️
Oh, there are definitely issues with ADC using non-Avid interfaces for sends/returns. I'm afraid I don't know enough about PT versions to say whether these problems are cleaned up now, but in earlier versions of PT, I saw myself that using the Avid interfaces, return tracks were sample-accurate in alignment, but were off by a few samples using other converters. I think one simple issue is that PT may not be cognizant of the actual sample delay of various interfaces/converters.

-synthoid
If you're using 3rd party standalone converters (ie connected digitally, not directly to the computer) there's no way PT can be aware of their latency - the only way to adjust it is to do it manually (in IO setup). And this is fiddly - a "ping" system would be better.

PT non-HD, using native interfaces - this SHOULD be sample accurate, because the Coreaudio driver can tell PT the converter latency. But rarely is on the examples I've tried. Don't know if this is PT or the coreaudio driver's fault.
Old 27th September 2012 | Show parent
  #17
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by psycho_monkey ➑️
If you're using 3rd party standalone converters (ie connected digitally, not directly to the computer) there's no way PT can be aware of their latency - the only way to adjust it is to do it manually (in IO setup). And this is fiddly - a "ping" system would be better.

PT non-HD, using native interfaces - this SHOULD be sample accurate, because the Coreaudio driver can tell PT the converter latency. But rarely is on the examples I've tried. Don't know if this is PT or the coreaudio driver's fault.
Is insert compensation the same thing as ADC?

If you turn ADC off, you'll still get your insert compensation right?
Old 27th September 2012 | Show parent
  #18
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by RyanC ➑️
I ran into a lot of ADC issues, especially noticeable as you say with parallel stuff on auxes in PTHD 8. In 10 HD|N I haven't had any problems at all. The only thing bugging me in 10 is that it won't always shift the compensation to audio tracks when it is possible to do so. Making it a bit of a hassle to monitor through your session.
This interests me. Why would you want to do that?


I found a time where doing that made things far easier for me. For the most part I think we're really only talking about drums, right?

The solution for me for this issue was to assign all of the drums to an audio hardware out that doesn't get monitored. It has to be an audio out and can't be a dummy bus. With no plug ins, they will all be compensated to the system delay and their timings won't change.

From there I use aux sends to send the tracks to submix busses or the stereo buss or both. Once I started doing this and also making sure any unique sends came back to their own return before the stereo buss, all of my problems went away.

What I can't tell yet is if this is a method that will work for any context or if it's working because of the choices I happen to be making in the few particular sessions I've been doing this on.
Old 27th September 2012
  #19
Gear Head
 
🎧 10 years
Quote:
Originally Posted by Mike Caffrey ➑️
ProTools 8 had compensation.

Because the interface isn't relevant. I'm using RADAR. Happy now? I'm curious why you care.
Quote:
Originally Posted by Mike Caffrey ➑️
Right, but ADC is software, not hardware.


So now what, I have to prove to you that I use ProTools with RADAR?


Regardless, my question has been answered. There are no issues with ADC because if there were the answer to the original question would have been to direct me to the ones that have problems.
What the hell is your problem pal? The poster you were responding to took the time to come in to this thread and try to respond to your query, and all you do is sit there grumbling a bunch of snarky ****.
Old 27th September 2012 | Show parent
  #20
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by child of Gaia ➑️
What the hell is your problem pal? The poster you were responding to took the time to come in to this thread and try to respond to your query, and all you do is sit there grumbling a bunch of snarky ****.
Read his posts more carefully.
Old 27th September 2012 | Show parent
  #21
Gear Nut
 
🎧 5 years
Quote:
Originally Posted by child of Gaia ➑️
What the hell is your problem pal? The poster you were responding to took the time to come in to this thread and try to respond to your query, and all you do is sit there grumbling a bunch of snarky ****.
I don't Mike was the person stepping out of line...


Quote:
Originally Posted by psycho_monkey ➑️
If you're using 3rd party standalone converters (ie connected digitally, not directly to the computer) there's no way PT can be aware of their latency - the only way to adjust it is to do it manually (in IO setup). And this is fiddly - a "ping" system would be better.

PT non-HD, using native interfaces - this SHOULD be sample accurate, because the Coreaudio driver can tell PT the converter latency. But rarely is on the examples I've tried. Don't know if this is PT or the coreaudio driver's fault.

"SHOULD" is the kicker. Coreaudio will never properly report firewire latencies. Or more to the point... it fluctuates periodically. Even systems using a "ping" like reaper can't deal with it.

The term "sample accurate" is a bit of a kicker as well. Even with avid interfaces it is still possible to have phasing issues related to ADC and parallel effects as the software cannot compensate for delays in the D to A and A to D stages of conversion which are less than a sample in size... Pull up something with a lot of high frequency content like drum overheads, parallel compress it using an outboard analogue compression and you'll see what I mean.
Old 27th September 2012 | Show parent
  #22
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by BasketCase Audio ➑️
"SHOULD" is the kicker. Coreaudio will never properly report firewire latencies. Or more to the point... it fluctuates periodically. Even systems using a "ping" like reaper can't deal with it.

The term "sample accurate" is a bit of a kicker as well. Even with avid interfaces it is still possible to have phasing issues related to ADC and parallel effects as the software cannot compensate for delays in the D to A and A to D stages of conversion which are less than a sample in size... Pull up something with a lot of high frequency content like drum overheads, parallel compress it using an outboard analogue compression and you'll see what I mean.
I'm surprised that everyone is talking about hardware insert delays connected to ADC. Isn't that considered something separate? Issues of delays smaller than a sample aside, those are fixed and once you set them, you're done.

My original question was intended to be about software latency and the way that ADC compensates when you add or remove a plugin.

And really, it's mostly connected to buss routing because there's more than one way to route something to get the same effect, but I think the options for how to do it and have ADC work are limited.

Maybe that's no longer an issue and the only issues are with hardware inserts.
Old 27th September 2012
  #23
Gear Nut
 
🎧 5 years
Quote:
Originally Posted by Mike Caffrey ➑️
I'm surprised that everyone is talking about hardware insert delays connected to ADC. Isn't that considered something separate? Issues of delays smaller than a sample aside, those are fixed and once you set them, you're done.

My original question was intended to be about software latency and the way that ADC compensates when you add or remove a plugin.

And really, it's mostly connected to buss routing because there's more than one way to route something to get the same effect, but I think the options for how to do it and have ADC work are limited.

Maybe that's no longer an issue and the only issues are with hardware inserts.
Plugin delay compensation refers to just plugins. Automatic delay compensation (adc) refers to everything, including then way latency is compensated for when inserting hardware effects into a mix.

How do you set anything regarding a fraction of a sample when the smallest increment is a single sample?

If you are only curious about PDC, don't sweat it. Its all been ironed out in protools.
Old 27th September 2012 | Show parent
  #24
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by BasketCase Audio ➑️
Plugin delay compensation refers to just plugins. Automatic delay compensation (adc) refers to everything, including then way latency is compensated for when inserting hardware effects into a mix.

How do you set anything regarding a fraction of a sample when the smallest increment is a single sample?

If you are only curious about PDC, don't sweat it. Its all been ironed out in protools.
PDC is what I'm most concerned about right now.

I'll tell you this, in ProTools 10 I can make some of the nastiest combfiltering you've ever heard with ADC on when I don't route following a very specific set of rules that I've made for myself.

But as far as I can tell, it does work right. I've been under the belief for a long time that it didn't and then when I had problems recently, I tested it with tones, which has a right way and a wrong way to do. I of course did it the wrong way and ended up on a wild goose chase.
Old 27th September 2012 | Show parent
  #25
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by Mike Caffrey ➑️
This interests me. Why would you want to do that?

I found a time where doing that made things far easier for me. For the most part I think we're really only talking about drums, right?

The solution for me for this issue was to assign all of the drums to an audio hardware out that doesn't get monitored. It has to be an audio out and can't be a dummy bus. With no plug ins, they will all be compensated to the system delay and their timings won't change.

From there I use aux sends to send the tracks to submix busses or the stereo buss or both. Once I started doing this and also making sure any unique sends came back to their own return before the stereo buss, all of my problems went away.

What I can't tell yet is if this is a method that will work for any context or if it's working because of the choices I happen to be making in the few particular sessions I've been doing this on.
Interesting, I've just been disabling the ADC on only the specific auxes that cause an issue, but I'm curious to try what you describe. The reason why I want to do it, is to be able to record through or monitor through the session, is that what you mean? I'm tracking/monitoring ITB most of the time.

Yeah drums would be the main one but I've run into the issue a little bit with a DI guitar to re-amp(s) tracking, or sometimes VE pro in a big session. So if I had say Kick In, Kick Out, Kick trig (aux), all feeding kick bus, which feeds the drum bus, which feeds the 2-bus. And the kick trig aux has 192 samples delay (trigger @96k), the individual audio tracks for say bass (which feed a band aux which feed the 2bus), can either compensate the 192 samples or, it can happen at the band bus.

When the band bus goes as a whole, you can't record/monitor the bass through PT without the latency of trigger, but if the ADC is shifted up one layer to all the audio tracks feeding the band bus, then when you record enable the track it auto-bypasses ADC and is good to. What version of PT are you using?
Old 27th September 2012 | Show parent
  #26
Gear Maniac
 
🎧 10 years
Quote:
Originally Posted by Mike Caffrey ➑️
PDC is what I'm most concerned about right now.

I'll tell you this, in ProTools 10 I can make some of the nastiest combfiltering you've ever heard with ADC on when I don't route following a very specific set of rules that I've made for myself.
First off, PT8LE did not have compensation, PT8HD did. Assuming you're on 10 now, you obviously have it. But there are easy ways to run into trouble with it, one of course being when it is turned off. Obviously you have to make sure it's turned on. I'm sure you know how the Playback Engine works.

That being said, the routing makes all the difference in terms of how your plugin delay adds up. I'm on PT9, and the 'Long' Delay Compensation setting gives you about 4000 samples to work with, not sure what PT10 gives you. This means that each plugin in your chain can only add up to 4000 samples. And by 'chain' I mean you have a single vocal track with some plugs, sending to a vocal sum with more plugs, sending to the master fader which probably has something like an L2 on it. The plugin delay on ALL of those tracks have to add up to less than 4000.

If you go to your Mix window, click on 'View'>'Mix Window View'>'Delay Compensation' and it will precisely display how many samples each track is delayed. (Apple+Option+M shows you a wider view if you can't see it in skinny view) Red numbers are bad! Green numbers are good. There is also a DLY light at the top of the transport, if it's RED, you have problems.

It should also be noted that when a plugin is on BYPASS, it will STILL delay. But when it is INACTIVE, it will not.

If you're just on a laptop and using only RTAS, that's pretty much all you need to know. But if you're on an HD rig, it goes further. The combination of TDM plugins and RTAS plugins can **** your **** up. If you run into problems, try switching some from TDM to RTAS or vice versa.
When you have an RTAS plugin, the processing happens at the computer's RAM. When you have a TDM plugin, the processing happens at the Pro Tools core card. If you have both, the data has to physically travel through that little cable to the core card, then all the way back to the internal processor and that takes time. Which is why you can sometimes get crazy delay times if you mix and match TDM versus RTAS. If you can get away with it, keep them all one or the other on a single track. If you run out of TDM, try printing some AutoTune plugins (AutoTune is usually the most common resource hog).
Old 28th September 2012 | Show parent
  #27
Moderator
 
psycho_monkey's Avatar
 
🎧 15 years
Quote:
Originally Posted by AASteveo ➑️
First off, PT8LE did not have compensation, PT8HD did. Assuming you're on 10 now, you obviously have it. But there are easy ways to run into trouble with it, one of course being when it is turned off. Obviously you have to make sure it's turned on. I'm sure you know how the Playback Engine works.

That being said, the routing makes all the difference in terms of how your plugin delay adds up. I'm on PT9, and the 'Long' Delay Compensation setting gives you about 4000 samples to work with, not sure what PT10 gives you. This means that each plugin in your chain can only add up to 4000 samples. And by 'chain' I mean you have a single vocal track with some plugs, sending to a vocal sum with more plugs, sending to the master fader which probably has something like an L2 on it. The plugin delay on ALL of those tracks have to add up to less than 4000.

If you go to your Mix window, click on 'View'>'Mix Window View'>'Delay Compensation' and it will precisely display how many samples each track is delayed. (Apple+Option+M shows you a wider view if you can't see it in skinny view) Red numbers are bad! Green numbers are good. There is also a DLY light at the top of the transport, if it's RED, you have problems.

It should also be noted that when a plugin is on BYPASS, it will STILL delay. But when it is INACTIVE, it will not.

If you're just on a laptop and using only RTAS, that's pretty much all you need to know. But if you're on an HD rig, it goes further. The combination of TDM plugins and RTAS plugins can **** your **** up. If you run into problems, try switching some from TDM to RTAS or vice versa.
When you have an RTAS plugin, the processing happens at the computer's RAM. When you have a TDM plugin, the processing happens at the Pro Tools core card. If you have both, the data has to physically travel through that little cable to the core card, then all the way back to the internal processor and that takes time. Which is why you can sometimes get crazy delay times if you mix and match TDM versus RTAS. If you can get away with it, keep them all one or the other on a single track. If you run out of TDM, try printing some AutoTune plugins (AutoTune is usually the most common resource hog).
You would hope, with Mike's pedigree, that he'd know the TDM-RTAS 101...I think this goes deeper than that. I'm sure he's quite aware not to exceed the delay compensation limits!
Old 28th September 2012 | Show parent
  #28
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by AASteveo ➑️
First off, PT8LE did not have compensation, PT8HD did. Assuming you're on 10 now, you obviously have it. But there are easy ways to run into trouble with it, one of course being when it is turned off. Obviously you have to make sure it's turned on. I'm sure you know how the Playback Engine works.

That being said, the routing makes all the difference in terms of how your plugin delay adds up. I'm on PT9, and the 'Long' Delay Compensation setting gives you about 4000 samples to work with, not sure what PT10 gives you. This means that each plugin in your chain can only add up to 4000 samples. And by 'chain' I mean you have a single vocal track with some plugs, sending to a vocal sum with more plugs, sending to the master fader which probably has something like an L2 on it. The plugin delay on ALL of those tracks have to add up to less than 4000.

If you go to your Mix window, click on 'View'>'Mix Window View'>'Delay Compensation' and it will precisely display how many samples each track is delayed. (Apple+Option+M shows you a wider view if you can't see it in skinny view) Red numbers are bad! Green numbers are good. There is also a DLY light at the top of the transport, if it's RED, you have problems.

It should also be noted that when a plugin is on BYPASS, it will STILL delay. But when it is INACTIVE, it will not.

If you're just on a laptop and using only RTAS, that's pretty much all you need to know. But if you're on an HD rig, it goes further. The combination of TDM plugins and RTAS plugins can **** your **** up. If you run into problems, try switching some from TDM to RTAS or vice versa.
When you have an RTAS plugin, the processing happens at the computer's RAM. When you have a TDM plugin, the processing happens at the Pro Tools core card. If you have both, the data has to physically travel through that little cable to the core card, then all the way back to the internal processor and that takes time. Which is why you can sometimes get crazy delay times if you mix and match TDM versus RTAS. If you can get away with it, keep them all one or the other on a single track. If you run out of TDM, try printing some AutoTune plugins (AutoTune is usually the most common resource hog).
PT8 LE is not relevant to this thread.

I appreciate your effort at explaining all of the other details. I apologize if I didn't make it clear that I'm not currently having any problems with ADC and as far as I can tell, I have a very good understanding of it. I'm looking for examples of other people having problems, especially in connection with buss routing, to see if these couple of rules that I've made for myself work in all situations or only the ones that I've thought up so far.
Old 28th September 2012 | Show parent
  #29
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by RyanC ➑️
Interesting, I've just been disabling the ADC on only the specific auxes that cause an issue, but I'm curious to try what you describe. The reason why I want to do it, is to be able to record through or monitor through the session, is that what you mean? I'm tracking/monitoring ITB most of the time.

Yeah drums would be the main one but I've run into the issue a little bit with a DI guitar to re-amp(s) tracking, or sometimes VE pro in a big session. So if I had say Kick In, Kick Out, Kick trig (aux), all feeding kick bus, which feeds the drum bus, which feeds the 2-bus. And the kick trig aux has 192 samples delay (trigger @96k), the individual audio tracks for say bass (which feed a band aux which feed the 2bus), can either compensate the 192 samples or, it can happen at the band bus.

When the band bus goes as a whole, you can't record/monitor the bass through PT without the latency of trigger, but if the ADC is shifted up one layer to all the audio tracks feeding the band bus, then when you record enable the track it auto-bypasses ADC and is good to. What version of PT are you using?
I'm on 10.3 HD-TDM.

By monitor through your session, do you mean monitor through your mix bussing or just monitor the tracks you're recording through the same stereo buss?


The mistake I was making was not thinking about where the ADC is applied. It's always applied at the end/return rather than the source/send.

If I'm understanding your routing right, I see two causes of problems.

With the kick routing, you've got the out put of to tracks going directly to a buss, which feeds another buss. Parallel to that is the kick trigger send which has a latency that you hear as a flam when it's returned to the buss that you're sending the two kick tracks to. Is that right? I'm not clear exactly where this trigger send is going or what's happening.

One of the rules I've made for myself is any send has to have its own return. I'd have try this, but I'm pretty sure that if you return the trigger to its own aux before combining it with the two kick tracks you'll have solved the problem. You'll have allowed ADC to calculate the delay and then give it a unique spot to correct it.

I had a similar situation where I had to aux returns summing in a third return which went to the stereo buss. I was using a send to allow a little of one of the initial auxes to bypass the third and go straight to the stereo buss. As soon as I gave it its own return, there was a spot for compensation to be applied.

The thing with the band buss, is that when you have busses in series, it applies compensation only at the second one. There's a logic to this, but I've forgotten it.


If send from an aux direct to the stereo buss and a second auxed to a buss, with plugins and that buss to a second buss with plugins there's no problem because ADC can total the compensation for the plugins on both busses in series and apply it all at the end. I think it may have to do with the fact that there's no way to predict what's happening before that buss and whether you've got things only going though it to the second or both going through it and around it, so it applies it all in one spot and you have to compensate with a dry buss of bypassed plugins.


That's a similar issue with your band buss. I'm guessing that you've got some bussing front of it. If everything went straight from the track out to that buss, there'd be no problem.

Here's the work around, it's a little odd, but it works.

Lets say you have drums, bass and guitar feeding your band buss. If you've got a drum bass and guitar buss, they won't have ADC applied, it will all happen at the band buss, but the problem is the band buss needs to compensate differently for each of those.

If the band buss has EQ only, you make three identical band busses and link the plugin controls and it's the same as running them through one, but they can all compensate differently as needed.

The one difference is the summing within the EQ. Most likely the increased head room from breaking things up will be a benefit.

The problem comes if you need summing, for instance with compression.

There's a work around for that too.


When you assign something to one of the three band busses, you'll need to send it to a 4th buss path as well. So drums bass and guitar each go to their own band buss as well as the same buss send.

Now assign all of the compressor sidechains to look at the buss send and you'll get the same summing for the compressor to react to. There may be combfiltering withing that sidechain, but it's not enough to affect timing and it never gets heard.

There's an advantage to this approach since you can now change balances while maintaining the same compression.


There's one possible flaw, which is ADC does something weird when you send to a dummy buss. I think it automatically applies the system delay, so if you assign the sidechain buss to an unused audio output, it will apply the right compensation, which should be none rather than the system delay. Ignore this whole part unless you have a problem with the first attempt.

If you want to have a compressor plugin on the band buss that doesn't have a key input, you're screwed.

I think that you could use tracks in input in place of auxes with ADC forced on which would put the ADC where it's not putting it because you have two auxes in series.


It's a lot to get through text. The routing is not hard once you've done it once.


Let me know which things work for you and which don't.


Do you track with ADC on or off?
Old 28th September 2012
  #30
Gear Head
 
Tim@ WOVEN audio's Avatar
 
🎧 5 years
Hi Mike,

I read through most of this thread. This is really interesting to me as I bounce around to different studios with different Pro Tools systems and also have one at home. I've experience all kinds of oddities with ADC and PDC (plugin delay compensation,, right?).

I get what you're saying about assigning all the drums to a HW output that isn't monitored.. then using aux sends to get the different drum tracks to different busses, etc. I know there are a million ways to route to busses, but would you mind explaining an example setup where you are experiencing problems that you then overcome by following your "rules" for fixing this. ie,, sending individual drum tracks to a drum buss, then to a mix buss, then to a print track.. or, sending individual drum tracks to various parallel busses, then to a master buss, then to print..

When you are experiencing these problems, are you also input monitoring or recording overdubs? How many layers deep are your busses?

This is interesting. Please break down an example for us.
Thanks.
πŸ“ Reply

Similar Threads

Thread / Thread Starter Replies / Views Last Post
replies: 295 views: 73842
Avatar for anguswoodhead
anguswoodhead 26th March 2013
replies: 15929 views: 1532163
Avatar for Ragan
Ragan 11th January 2019
replies: 1296 views: 181074
Avatar for heraldo_jones
heraldo_jones 1st February 2016
Topic:
Post Reply

Welcome to the Gearspace Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…

Forum Jump
Forum Jump