Quantcast
Does ADC work? - Page 2 - Gearspace.com
The No.1 Website for Pro Audio
Does ADC work?
Old 28th September 2012
  #31
Gear Head
 
Tim@ WOVEN audio's Avatar
 
🎧 5 years
I see you did indeed break it down right before I finished asking about it. That is sort of a lot to go through in text form. I'd be interested to see one of your sessions and be able to go through it bit by bit. It's sort of similar to how I set things up, but I'm not totally sure I understand all of it.

I sort of keep it simple, in that I usually just use four group busses, feeding a master fader into a print track. That seems to usually not trip up Pro Tools' ADC calculations too much. On PT 8 systems it seems like it works sometimes and doesn't others. But if it's not working, it's really obvious and a restart of Pro Tools will usually fix it.

Anyway, thanks for expounding.
Old 28th September 2012 | Show parent
  #32
Lives for gear
 
🎧 15 years
I find this thread particularly interesting.... I used to b on cubase 4, all the while mixing plugins, hardware inserts , Paralell processing etc.... And I never had a problem.... Ever! Never heard a flam, everything always sounded real tight.... I could even use a tape machine as an insert! Using ping, cubase would set it all up straight...

Since I started using PThd8, flams seem to appear at the start of every mix session.... When I record, I usually set up bus 1-2 to fed an aux I call HEADAMP.... Headamp's input is bus1-2 and it's output is analog 15-16. 15-16 is sent out to the headphone amp....Everything during tracking usually goes down fine.... I'll use a few plugins, trim, eqs etc.... No problems...

Come mix, I'll throw a hardware insert on the kick and snare to start.... BAM flaming... Every time....

For some reason, deleting my aux HEADAMP solves the problem....

Figure that one out for me?....smells fishy to me...
Old 28th September 2012 | Show parent
  #33
Gear Head
 
Tim@ WOVEN audio's Avatar
 
🎧 5 years
Quote:
Originally Posted by passenger ➑️

Come mix, I'll throw a hardware insert on the kick and snare to start.... BAM flaming... Every time....

For some reason, deleting my aux HEADAMP solves the problem....

Figure that one out for me?....smells fishy to me...
I've experienced the exact same thing. I wish I did understand this better. Does anyone know if there is any good literature from Avid about the inner workings of their ADC?
Old 28th September 2012 | Show parent
  #34
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by [email protected] WOVEN audio ➑️
I see you did indeed break it down right before I finished asking about it. That is sort of a lot to go through in text form. I'd be interested to see one of your sessions and be able to go through it bit by bit. It's sort of similar to how I set things up, but I'm not totally sure I understand all of it.

I sort of keep it simple, in that I usually just use four group busses, feeding a master fader into a print track. That seems to usually not trip up Pro Tools' ADC calculations too much. On PT 8 systems it seems like it works sometimes and doesn't others. But if it's not working, it's really obvious and a restart of Pro Tools will usually fix it.

Anyway, thanks for expounding.
Take your four busses and add parallel compression infront.

I think the way you'll most likely do that is a dry buss and a compressed buss and balance them.

Suppose you wanted some of the entire kit uncompressed. The easiest way would be to send it from the dry buss via an aux send to the stereo/print buss. That signal will arrive ahead of the the signal that goes through the second buss for non parallel compression and you'll have comb filtering.

Lately I've been making a dry buss, a compressed buss of only close mics, sometimes gated even and a room mic buss. That allows heavy compression without adding the cymbal upsuck and it's very easy to automate balance changes. The rooms can be smashed even more than when they were tracked, but it will be smooth because the close kick and snare won't create ducking and releasing.

This is where all the dynamic range reduction happens. Then when they are summed and compressed again, it's with a far more subtle compression and it's almost always sidechained rather than allowing the detector to look at the signal passing through.

Sidechaining allows me to ignore certain hits, so that it reacts only to kick hits on 1 and 3 and ignores any that might be on the ands. I'll either duplicate the kick and chop it or I'll use a click track. If it's a chopped kick, I'll usually strip silence and make all of the kicks the same length and short. Then I'll peak limit it so that it has no dynamic range before it hits the sidechain/key input. That way I can be extremely precise about how the audible pumping is heard (or not heard) and there are no stray loud or soft kicks to screw it up.

So I'm separating rooms, dynamic range reduction and glue in to separate controllable busses.
Old 28th September 2012 | Show parent
  #35
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by passenger ➑️
I find this thread particularly interesting.... I used to b on cubase 4, all the while mixing plugins, hardware inserts , Paralell processing etc.... And I never had a problem.... Ever! Never heard a flam, everything always sounded real tight.... I could even use a tape machine as an insert! Using ping, cubase would set it all up straight...

Since I started using PThd8, flams seem to appear at the start of every mix session.... When I record, I usually set up bus 1-2 to fed an aux I call HEADAMP.... Headamp's input is bus1-2 and it's output is analog 15-16. 15-16 is sent out to the headphone amp....Everything during tracking usually goes down fine.... I'll use a few plugins, trim, eqs etc.... No problems...

Come mix, I'll throw a hardware insert on the kick and snare to start.... BAM flaming... Every time....

For some reason, deleting my aux HEADAMP solves the problem....

Figure that one out for me?....smells fishy to me...
Extra cost aside, is there a reason to use the hardware insert instead of an analog summing buss?
Old 28th September 2012 | Show parent
  #36
Gear Maniac
 
🎧 10 years
Quote:
Originally Posted by Mike Caffrey ➑️
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.
Seriously, I don't even know why I bother with this forum anymore.
Old 28th September 2012 | Show parent
  #37
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by AASteveo ➑️
Seriously, I don't even know why I bother with this forum anymore.
It's a shame there aren't moderators here. GS would be a much better place if certain types of posts were discouraged and if people were encouraged to post under their real name.
Old 28th September 2012 | Show parent
  #38
Lives for gear
 
synthoid's Avatar
 
🎧 15 years
+1 for moderation. some of the comments in this thread are just ridiculous.

What's the OP is doing strikes me as pretty clever because it goes right to the heart of ADC as a graph algorithm. By creating matching send and return points, you're forcing the graph to be "structured" in the sense of having properly nested single-entry single-exit regions, and those regions give the algorithm clear points for delays to be introduced. My guess is that this solution, being pretty 'deep' in that sense, will probably be pretty robust.

I have to say that I'm a bit surprised though that it is ever necessary to do such a thing unless hardware inserts are involved. Hardware inserts are a bit tricky because the DAW has to understand the signal flow outside of itself (in the patchbay) to get things right. But in the case of a cycle-free routing strictly inside the DAW, I can't see why things would ever be incorrectly compensated in a way that is audible. There is an airtight and complete algorithm for PDC inside the DAW (no hardware inserts involved) that should get it right every time.

Maybe I'm missing something though and there's a complication that I'm not aware of ...

-synthoid
Old 28th September 2012
  #39
Lives for gear
 
🎧 15 years
The last part is ultimate what drove me to ask the question of whether it works. If I'm doing something that seems normal to me and hearing comb filtering, why would that be?

My current belief is that ADC does work properly and that the problems I was having were from not understanding where the delay was being applied.

Also, almost every session I work on ends up in the vicinity of 192 voices. In some cases that's after printing some things as stems. It's also partly because of how bussing uses voices.

If you're mixing a band that's drums, bass, two guitars and vocal, you'd ideally have two stereo tracks and two mono tracks and then ride them through out the song. When someone uses multiple mics on the drums and guitars and guitar double you can buss those things down to that simple a set up. ADC is fine for this

The problem mainly comes from use of parallel processing. There are times when I can make a dry bus and a processed buss with plugins only on the processed buss and not have comb filtering. Others I have to have duplicated, bypassed plugins.

The problem I had was that some of the way I control compression is through routing.

Let's say that you have a band and the kick drum is a sample, no live kick, but the rest of the drums are live. If you buss that kick track together with the drums as the density of the drumming changes or the volume changes the volume of that kick sample will go up and down with the compressor's gain reduction. The reason to have such and odd instrumentation is to have a static level from the kick sample. You could buss that separately, but then the kick isn't contributing to the drum compression.

A simple solution is buss all the drum tracks together and then use an aux send to send some of the kick sample directly to the stereo/print bus. That will make the sample's level more static and still contribute properly to the drum compression.

When I did this, the "drum compression" was a dry bus and compressed buss in parallel summed into an overall compressed buss. Rather than send the kick sample I wanted to send some of the parallel compressed buss directly to the stereo buss - long story why, but it makes sense. That's when the problems happened.

The solution is to have an extra buss to allow the compensation for that direct send to happen since you've sent it on a shorter path.


So some of my problems were my lack of understanding ADC's routing requirements, but I still have a few inconsistent experiences with the parallel busses, so it's easy to doubt ADC and not look for your mistake.

I still don't understand my problems are intermittent with parallel processing, although I know how to solve it.

So it leaves me with the question, does ADC work in all cases and I always need to look for a user error or are there cases where the problem is with ADC.

I had go spend a lot of time learning ADC to understand where my problem was happening. It's such a non-issue in the analog world that it wasn't instinctual to find - for me at least.
Old 29th September 2012
  #40
Lives for gear
 
🎧 15 years
Hmm right, auxes are certainly what makes adc confusing. I'm really interested in your trick of using auxes to feed a compressor's sidechain...going to have to play with that.

My simple version would be ABC tracks feed aux 1 and XYZ tracks feed aux 2 and auxes 1 and 2 feed "2bus aux", which maybe has sends to cans and internal routing for a print. Once tracks ABC are cut I put a high latency plug on aux 1. Everything is working great until I arm track X, in which case it has the latency from aux 1 even though it shouldn't have to if the actual tracks had the ADC instead of the aux having it. The interesting thing is if I route the armed track to the 2bus aux, it shifts the adc to the track level and then works the way I would want it to (for all the tracks routed to "2bus").

In native only a handful of plugins have any latency, most normal stuff registers as 0.
Old 29th September 2012 | Show parent
  #41
Lives for gear
 
synthoid's Avatar
 
🎧 15 years
In my opinion, there's a bug somewhere. There is no reason that you should be able to create a parallel structure, hear improper delay compensation (i.e., failure to delay one of the parallel routes properly), and be able to fix it by putting in plugs and bypassing them. "putting in plugs and bypassing them" is exactly what the PDC algorithm does for a living, only it does it of course by simply introducing a small delay line in the alternate path.

That doesn't help you much, but that's my opinion.

That said, if this is only happening when you're pushing the voice count to the limit; or when you use such-and-such a particular plug-in whose delay might be accounted for incorrectly by PT; or some other particular situation that explains it, then maybe it's not a bug deep in the PDC algorithm. But it sure looks like that from your description.

-synthoid
Old 29th September 2012 | Show parent
  #42
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by RyanC ➑️
Hmm right, auxes are certainly what makes adc confusing. I'm really interested in your trick of using auxes to feed a compressor's sidechain...going to have to play with that.

My simple version would be ABC tracks feed aux 1 and XYZ tracks feed aux 2 and auxes 1 and 2 feed "2bus aux", which maybe has sends to cans and internal routing for a print. Once tracks ABC are cut I put a high latency plug on aux 1. Everything is working great until I arm track X, in which case it has the latency from aux 1 even though it shouldn't have to if the actual tracks had the ADC instead of the aux having it. The interesting thing is if I route the armed track to the 2bus aux, it shifts the adc to the track level and then works the way I would want it to (for all the tracks routed to "2bus").

In native only a handful of plugins have any latency, most normal stuff registers as 0.
When you arm X, ADC will turn off.

The latency is coming from 2 matching 1 and it needs to do that for Y and Z to match ABC. Those could all be drum tracks with 1 and 2 being a L/R buss.

When you route the track to the stereo buss it's going to arrive ahead of everything else, so delay compensation has to be applied there.

The way I came to the idea of sending to an unmonitored audio out is that everything is matched to be in phase when it hits the main stereo audio out, so sending directly to the stereo buss means the track out needs the longest aux delay added, unless there's another track going to the stereo audio out with more latency that the buss chain.

That's how it works for playback for sure, but isn't the ADC being turned off on the track you're recording?
Old 29th September 2012 | Show parent
  #43
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by synthoid ➑️
In my opinion, there's a bug somewhere. There is no reason that you should be able to create a parallel structure, hear improper delay compensation (i.e., failure to delay one of the parallel routes properly), and be able to fix it by putting in plugs and bypassing them. "putting in plugs and bypassing them" is exactly what the PDC algorithm does for a living, only it does it of course by simply introducing a small delay line in the alternate path.

That doesn't help you much, but that's my opinion.

That said, if this is only happening when you're pushing the voice count to the limit; or when you use such-and-such a particular plug-in whose delay might be accounted for incorrectly by PT; or some other particular situation that explains it, then maybe it's not a bug deep in the PDC algorithm. But it sure looks like that from your description.

-synthoid
I think it's only happening when there are two busses in series, not counting the stereo buss. The first buss will not have ADC applied.
Old 29th September 2012 | Show parent
  #44
Lives for gear
 
synthoid's Avatar
 
🎧 15 years
Quote:
Originally Posted by Mike Caffrey ➑️
I think it's only happening when there are two busses in series, not counting the stereo buss. The first buss will not have ADC applied.
But there must be more to the situation that causes the bug than simply a bus following another bus. Fundamentally, the need for compensation comes from 'parallel' and not 'series'. And comb-filtering is essentially a 'parallel' phenomenon, of a signal with a delayed copy of itself overlaid.

Earlier you wrote "The problem mainly comes from use of parallel processing." And your description was of a fairly complicated parallel routing / compression scheme that you used to keep kick level up while compressing a drum bus, something like that.

Anyhow, whatever the cause, I think this much is fair to say: there is no circumstance under which you should be able to insert a disabled plug-in and cause an audible difference in the output of PT, unless you're using hardware inserts. (HW inserts can be evil because you can fold them directly into your monitor mix via the patchbay/console and do other things that are out of bounds as far as the ADC algorithm is concerned.) If that happens -- inserting a disabled plug changes comb-filtering -- then there is a bug to be reported. IMO. So maybe you could put together a session where inserting a disabled plug in a specific spot changes what you hear; and toss the thing over to Avid for their comment.

See, the other thing about the solution of "inserting a disabled plug" is that it leaves open the possibility that the real problem is simply that PT is using the wrong latency number for that plug. There are other possibilities, like that the scheduler can't keep up as you push the voice count to the max, or that there's a more fundamental bug in the ADC algorithm. But it's hard to rule anything out if inserted a bypassed plug fixes it, because it might simply be that PT is using the same wrong latency figure on both paths, and that's why it fixes the comb-filtering.

interesting problem...

-synthoid
Old 29th September 2012 | Show parent
  #45
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by synthoid ➑️
But there must be more to the situation that causes the bug than simply a bus following another bus. Fundamentally, the need for compensation comes from 'parallel' and not 'series'. And comb-filtering is essentially a 'parallel' phenomenon, of a signal with a delayed copy of itself overlaid.

Earlier you wrote "The problem mainly comes from use of parallel processing." And your description was of a fairly complicated parallel routing / compression scheme that you used to keep kick level up while compressing a drum bus, something like that.

Anyhow, whatever the cause, I think this much is fair to say: there is no circumstance under which you should be able to insert a disabled plug-in and cause an audible difference in the output of PT, unless you're using hardware inserts. (HW inserts can be evil because you can fold them directly into your monitor mix via the patchbay/console and do other things that are out of bounds as far as the ADC algorithm is concerned.) If that happens -- inserting a disabled plug changes comb-filtering -- then there is a bug to be reported. IMO. So maybe you could put together a session where inserting a disabled plug in a specific spot changes what you hear; and toss the thing over to Avid for their comment.

See, the other thing about the solution of "inserting a disabled plug" is that it leaves open the possibility that the real problem is simply that PT is using the wrong latency number for that plug. There are other possibilities, like that the scheduler can't keep up as you push the voice count to the max, or that there's a more fundamental bug in the ADC algorithm. But it's hard to rule anything out if inserted a bypassed plug fixes it, because it might simply be that PT is using the same wrong latency figure on both paths, and that's why it fixes the comb-filtering.

interesting problem...

-synthoid
We may be using non-interchangable terms interchangably

To me "disabled plugin" means a plugin on an insert where you've clicked on it while holding command and control and it's greyed out. If you click on it while greyed out the plugin opens and it says "inactive"

I have not found inserting a disabled plugin to have an effect in parallel processing.

What I'm talking about inserting is a bypassed plugin in. In the insert it will not appear as on, but it's not greyed out. When you click on it you see the controls and the bypass button has been selected.
Old 30th September 2012 | Show parent
  #46
Gear Head
 
🎧 5 years
Hey Mike. ADC isn't perfect. Mostly because 3rd party plugs report delay incorrectly. When tho shappens obviously there will be phase issues.

For the sake of my sanity and because chasing delay gremlins makes me want to slit my wrists, with multiple recorded REAL drum tracks I just tend to do the following...


Set up a drum buss make two or three aux with the same drum buss input...use the first as my general drum buss and the other two as parallel, but but insert all the same plugs across the three busses and just "bypass" (no inactive!) all the plugs on the first and whatever plugs on the other two, use the fader to mix the amount of parallel..and bob is your uncle...all drums are assigned tooth drum buss...that way you are dead on ITB always...no calculations or chasing...done save those sends for effects!

PS. inserting plugs while you are playing a track will cause improper delay comp sometimes...only when you stop and start again will it fix.
Old 30th September 2012 | Show parent
  #47
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by stanmisner ➑️
Hey Mike. ADC isn't perfect. Mostly because 3rd party plugs report delay incorrectly. When tho shappens obviously there will be phase issues.

For the sake of my sanity and because chasing delay gremlins makes me want to slit my wrists, with multiple recorded REAL drum tracks I just tend to do the following...


Set up a drum buss make two or three aux with the same drum buss input...use the first as my general drum buss and the other two as parallel, but but insert all the same plugs across the three busses and just "bypass" (no inactive!) all the plugs on the first and whatever plugs on the other two, use the fader to mix the amount of parallel..and bob is your uncle...all drums are assigned tooth drum buss...that way you are dead on ITB always...no calculations or chasing...done save those sends for effects!

PS. inserting plugs while you are playing a track will cause improper delay comp sometimes...only when you stop and start again will it fix.
That's what I do. I don't have problems with that. My problems were in a different part of the routing.

Can you cite any specific plugins that report their delays wrong?

I can't always create comb filtering between parallel busses that don't have identical plugins.

I've still been unable do find a problem with ADC that's not connected to not allowing a place for ADC to be applied.

As far as I can tell, ADC is perfect, but I want to find the flaws if there are any.
Old 30th September 2012 | Show parent
  #48
Gear Head
 
🎧 5 years
Also I notice a very complex way of routing for parallel. I can;t quite figure out what you mean, but when I want to send certain elements of the kik only to certain parallel situation I would create three separate busses with all the same plugs with whatever bypassed and SEND whichever elements you choose to that...ay and all busses should then be assigned to a general drum buss.

I don't trust ADC to work properly. I use paranoid workflow methods to make sure I never have to worry about it.
Old 30th September 2012 | Show parent
  #49
Gear Head
 
🎧 5 years
izotope alloy, ozone...flux...waves in general.

One time I had a vocal all of a sudden turn comby/phasey. The artist noticed immediately as I was flipping through some crap looking for something. I started muting some of the routing...turns out it was an aux that was an FX return. I had to blow it out and make a new one. So yeah that was a gremlin for sure. I think gremlins tend to appear more when you are opening a session from an earlier version of someone else's session. I alway seem to experience little "what the..?"s
Old 30th September 2012 | Show parent
  #50
Gear Head
 
🎧 5 years
I don't think ADC is perfect. Not by a long shot. I would NOT trust it. I think using a standard workflow that yields solid results is the key if you have to rely heavily on ADC.

I'm working my way towards using ALL DSP AAX ALL THE TIME. Whnever I do this, I never have problems.
Old 30th September 2012 | Show parent
  #51
Lives for gear
 
synthoid's Avatar
 
🎧 15 years
Quote:
Originally Posted by Mike Caffrey ➑️
We may be using non-interchangable terms interchangably
My bad, I meant bypassed plugs. It should not be possible to change the audible output of PT by inserting bypassed plugs. Their only effect is on latency, which should be automatically compensated. Inserting them is equivalent to what the PDC algorithm should be doing on its own.

-synthoid
Old 30th September 2012 | Show parent
  #52
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by synthoid ➑️
My bad, I meant bypassed plugs. It should not be possible to change the audible output of PT by inserting bypassed plugs. Their only effect is on latency, which should be automatically compensated. Inserting them is equivalent to what the PDC algorithm should be doing on its own.

-synthoid
I agree that it shouldn't, but I've experienced it happening.
Old 30th September 2012 | Show parent
  #53
Lives for gear
 
synthoid's Avatar
 
🎧 15 years
Quote:
Originally Posted by Mike Caffrey ➑️
I agree that it shouldn't, but I've experienced it happening.
exactly. so I think if you cobbled together a session where you can insert a bypassed plug and get a different output, then send it to Avid, you could tell them that you think it's a bug and ask if they agree or could comment. They might be able to shed some light on it...

-synthoid
Old 30th September 2012 | Show parent
  #54
Lives for gear
 
🎧 15 years
Quote:
Originally Posted by synthoid ➑️
exactly. so I think if you cobbled together a session where you can insert a bypassed plug and get a different output, then send it to Avid, you could tell them that you think it's a bug and ask if they agree or could comment. They might be able to shed some light on it...

-synthoid
At the moment, I can't create the problem in a session I'm building just for testing. I have to find an old one.
Old 30th September 2012
  #55
Gear Head
 
2 Reviews written
🎧 15 years
Issues with parallel routing and PDC are one reason I wish ALL compressor plugs had a wet/dry mix knob. This wouldn't eliminate all issues, as parallel routing is used in other ways, but it would make parallel compression pretty foolproof from the standpoint of PDC.

Sent from my PC36100
Old 30th September 2012 | Show parent
  #56
Gear Head
 
Tim@ WOVEN audio's Avatar
 
🎧 5 years
Quote:
Originally Posted by Mike Caffrey ➑️
Take your four busses and add parallel compression infront.

I think the way you'll most likely do that is a dry buss and a compressed buss and balance them.

Suppose you wanted some of the entire kit uncompressed. The easiest way would be to send it from the dry buss via an aux send to the stereo/print buss. That signal will arrive ahead of the the signal that goes through the second buss for non parallel compression and you'll have comb filtering.

Lately I've been making a dry buss, a compressed buss of only close mics, sometimes gated even and a room mic buss. That allows heavy compression without adding the cymbal upsuck and it's very easy to automate balance changes. The rooms can be smashed even more than when they were tracked, but it will be smooth because the close kick and snare won't create ducking and releasing.

This is where all the dynamic range reduction happens. Then when they are summed and compressed again, it's with a far more subtle compression and it's almost always sidechained rather than allowing the detector to look at the signal passing through.

Sidechaining allows me to ignore certain hits, so that it reacts only to kick hits on 1 and 3 and ignores any that might be on the ands. I'll either duplicate the kick and chop it or I'll use a click track. If it's a chopped kick, I'll usually strip silence and make all of the kicks the same length and short. Then I'll peak limit it so that it has no dynamic range before it hits the sidechain/key input. That way I can be extremely precise about how the audible pumping is heard (or not heard) and there are no stray loud or soft kicks to screw it up.

So I'm separating rooms, dynamic range reduction and glue in to separate controllable busses.
Thanks for this explanation, Mike. Totally makes sense what you are saying now. I appreciate it. This is a valuable thread for trying to understand ADC. I think that ADC sometimes gets confused or wonky and a comby/ phasey thing will happen that will then go away upon restarting the session (assuming you're not tricking it by doing the above mentioned routing). I'm not sure if that still happens in version 10, but it definitely happened a lot in version 8, less so in version 9, I think.

A lot of times, I'm just using parallel processing on a few things, like Kick and Snare and Bass and Vocals. So, I'm usually just duplicating the track, treating as parallel and balancing the two,, or three, or more. No problem with ADC in those situations. Those parallels then feed my four busses which feed my two buss which feeds the PRINT track.
Old 30th September 2012
  #57
Lives for gear
 
nickelironsteel's Avatar
 
🎧 5 years
deleted by user
Old 12th October 2012 | Show parent
  #58
Lives for gear
 
🎧 15 years
Everything has been great with ADC since following those rules until last night. I can't figure out exactly what the problem is, except maybe I ran into a plugin that wasn't reporting its latency right - McDSP multiband compressor.

I had the kick going through two busses in series which then feed an instrumental buss which feeds a print buss for monitoring and a track for printing.

I wanted to also route the kick directly to the print buss which I've been doing regularly without hearing a problem.

What I do is send to a buss that's just a return for that kick and it feeds the print buss. I could see compensation applied and it looked like it was the right amount, but it was very easy to hear comb filtering.

Later in the mix I found some combfiltering cause by a misaligned kick sample and after fixing that, tried the direct to print bus again and it was fine. It's possible that I was hearing that, but there was a distinct patter to the way it was changing and there was no patter of changing earlier. It's possible that I'd set something up weird, but I tried over and over and remade the buss and never found the problem.

One thing that changed was that I'd pulled that McDSP plugin off the second of the two busses in series. If that was misreporting, that could explain the problem.


There's one other problem I saw that I can't explain and I've seen it twice in the past week.

I've got three parallel busses in one spot. I make sure to use the same plugins on all three and I don't usually have problems. Usually they show the delay and no compensation since it's applied at the buss that follows.

Last night the 3rd buss was showing a small amount of compensation.

There were three sends to hardware inserts with manual compensation since I'm not using Digi converters on that buss, however I'd done the same thing in the mix right before and this didn't happen.

When I disabled all of the plugins on the three busses by control-clicking, they all showed no delay and no compensation and when I enabled them all, they showed the same delay as they should and now all three showed no compensation as they should.

So somehow, something made that one buss compensate when it shouldn't.

It's possible that early on I'd had different plugins on the three busses as I was working on them and deciding which would be the final choices. Maybe when I removed plugins and made them match it didn't reset properly?

It's also likely that I dragged the plugins from one buss to another rather than pull them from the list.

I can't remember if I restarted while having the parallel problem, but I definitely restarted with the first one and that didn't help.

Also, while the third buss was showing compensation when it shouldn't, I control-clicked on the compensation value for all three turning them all off and they sounded right, so while there may only be a small glitch that's easy to catch and fix, there was definitely an error.
Old 12th October 2012 | Show parent
  #59
Lives for gear
 
🎧 10 years
Thanks for all the info Mike.
PT 10 HD native here and I do have some PDC problems from time to time, which is obvious with parallel processing. I initially suspected some plugins to report incorrect values but I'll look into the bus thing more in detail.
I also noticed bypassing some plugs with cmd + click sometimes breaks the PDC.
A.
Old 12th October 2012
  #60
Lives for gear
 
nickelironsteel's Avatar
 
🎧 5 years
from the 10.3.1 (oct 3) update:

Automatic Delay Compensation
Delay Compensation may now be enabled for plug-in sidechains in the Operation preferences. (HDX hardware-accelerated systems only).

so no it didnt work, and no it doesnt work for non HD Systems. What a f'ing joke. I want my money back.
πŸ“ Reply

Similar Threads

Thread / Thread Starter Replies / Views Last Post
replies: 295 views: 74380
Avatar for anguswoodhead
anguswoodhead 26th March 2013
replies: 15929 views: 1533487
Avatar for Ragan
Ragan 11th January 2019
replies: 1296 views: 181889
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