Could someone explain me something about ADC please?

[mixaudio]

A common way to deal with plug-in delay, has been selecting all audio regions on a track that has a "delaying" plug-in, and nudging them earlier in time by the amount of samples they're being delayed by the plug-in, which puts the audio back in sync with tracks that have no plug-ins or tracks with plug-ins that cause minimal or no delay. This doesn't seem too complicated, yet when dealing with different delay times from different tracks, it may be difficult to keep track of which tracks have been manually shifted and the individual amounts of samples they've been nudged.

Until now, my understanding about ADC in HD systems is that a dedicated delay engine (which uses DSP) makes every track to be delayed by a certain amount to match the tracks with delaying plug-ins. If this is correct, wouldn't it be a lot easier and less complicated and less CPU demanding just to implement a feature that would make the audio on each track play earlier in time by as many samples as the plug-in on that track reports to be delaying the audio?

Also, if you notice, when we process audio with Audiosuite plug-ins, no delay is introduced in the resulting rendered audio. Wouldn't this happen also if our tracks could be frozen?? since the resulting "frozen" audio would be processed pretty much in the same offline way that Audiosuite works.

Please, enlighten me… fellow users, or Digi reps… I might be missing something, or the ADC development team (if such thing exists) could be focusing on a simpler solution.

Thanks!

Rodolfo F.

[Phil Ogden]

There is alternative methods of dealing with PDC. This thread may help,

http://duc.digidesign.com/showthread.php?t=230181

Also, Mellowmuse make a plug-in that takes the above mentioned method a step further.

http://www.myspace.com/philogg

[mixaudio]

Originally Posted by Phil Ogden

There is alternative methods of dealing with PDC. This thread may help,

http://duc.digidesign.com/showthread.php?t=230181

Thanks for the reply Phil, interesting method of saving CPU by bussing several tracks that are not using delaying plug-ins to an aux track with a Time Adjuster delay so they get a positive offset and puts them in sync with the track with the delaying plug-in. Yet, how would this work when we're dealing with more than one track with different plug-ins causing delay??? Say you got 2 tracks with delaying plug-ins. One delays the signal by 700 samples, and the other shows 1400. Now you'd have to decide a delay value for all the non affected tracks to match either 700 or 1400.

Still, I'm thinking that offsetting the tracks with delaying plug-ins to play earlier in time (since each of them would do it with it's own amount, based on the amount of delay reported by the plug-in) should have a better benefit, considering also that these would be a minority in the session. So, just a few tracks would be playing their audio earlier while the majority is actually playing with either no plug-ins or very short delaying plug-ins.

Rodolfo F.

[Numi]

you would need to delay everything to the longest delayed track..and if other tracks have some sort of delay already themselves you need to do a little math and use the plugin to delay all other tracks to add up to the longest delayed track. In your example..you would need to add 1400 samples of delay on tracks with no delay..and 700 samples of delay to the track that has 700 samples of delay already..700+700=1400. Hope this helps!

P.S.It seems nudging the audio files affected by delay forward in time to compensate would work too...but some might say it would be difficult to keep track of once you add more files and more effects(also this might effect timeline related material?)...guess you could make notes under the track name area to keep any nudged changes for later edits. This method would be less cpu intensive as well, I could see this good for small projects or projects that are in their final stage and won't be needing anything else added.

[mixaudio]

Well, that's my point precisely. Instead of offsetting audio earlier in time manually by nudging regions, why not have a little menu on each track to manually set an individual negative offset value??

What about this? If you go to your "Setup" menu in PT, there's an option named "Video Sync Offset…"

They already put this function to add an offset to video playback an you can enter a negative or positive value. How difficult could it be to add a little menu on the tracks to set a negative value and make them play earlier in time as well? I wouldn't mind if it's not automatic, as long as each track could do it's own offset value.

On MIDI tracks this can be done too, and in 2 different ways: A) under "Event" menu, go to "MIDI Tracks Offsets" option and the rest is self explanatory, or B) bring in the "Real-Time Properties" floating window and set a negative delay value for any MIDI track individually (can't adjust it in samples, but milliseconds works fine).

I think that when we set "Video Sync Offset…" or "MIDI Tracks Offsets" to a negative value (which makes the video or MIDI play earlier in time) we're not causing a great CPU load and with this "negative" delay amount we're compensating and putting those tracks in sync with everything else that doesn't require a delay.

Still, if this looks complicated, give us a Track Freeze function and that should solve a lot of the ADC problem as I was explaining on my first post here.

Rodolfo F.

[mixaudio]

Is this thing I'm suggesting something that had been discussed before?

Getting a menu/field to manually assign negative offsets for audio playback independently for each audio track??

Or everyone is so tired of discussing ADC??

I was hoping to get more enlightment about how this could be a good solution or some responses letting me know how wrong and crazy I am.

How about the track freeze function and the idea that audio on frozen tracks would not have any delay since it will be rendered Audiosuite style, which introduces no delay?

Rodolfo F.

[mixaudio]

bump…