preserving dialog editor's volume automation

[Eric L]

I just keep the dx tracks in trim mode. I'll investigate the pre existing track automation further if I run into problems, but that is rare. I usually start the dx predub by grabbing all the automation for the dx tracks and globally raising them or lowering them to get them in the ballpark, then I stay in trim mode.

As a matter of fact, I use this same technique for MX, SFX and Foley as well. Broad strokes first, then more detail as budget and time allow.

[minister]

True. What I've been doing is using the Q10 as an RTAS plug-in. This distortion then does not occur. I think it's because the RTAS is 32 bit float.

I can't find this statement in any of the Digi Whitepapers. PT can't mix 16 and 24 bit. How does it mix 32 and 24 (48)?

It may be true that the RTAS behave differently, or Marti has hotter dialog.

[TheHenchman]

I can't find this statement in any of the Digi Whitepapers. PT can't mix 16 and 24 bit. How does it mix 32 and 24 (48)?

It may be true that the RTAS behave differently, or Marti has hotter dialog.

I found some info for you:

http://www.digidesign.com/index.cfm?...0&itemid=15523

[minister]

I found some info for you:

http://www.digidesign.com/index.cfm?...0&itemid=15523

Mark, that link states what I understand: LE is 32 bit float and TDM is 48 bit precision. That page talks about interchanging sessions between platforms. So it explains why you will have clipping on an HD rig where you didn't on the LE.

It says nothing about RTAS plugs being 32 bit floating in the FIXED 48 bit Double precision environment of HD. I would think the math to pull that off would be more than convoluted.

[TheHenchman]

Mark, that link states what I understand: LE is 32 bit float and TDM is 48 bit precision. That page talks about interchanging sessions between platforms. So it explains why you will have clipping on an HD rig where you didn't on the LE.

Except that I've had sessions I've edited and premixed in LE, imported into HD, and now dialog is distorting and clippen.
Exchange the Plug-in to an RTAS plug-in, distortion gone.
I remeber readinf somewhere, that thr RTAS plug-ins still operate internally on a 32 bit floating process.

[Sonsey]

This is most likely, since the ACTUAL plugs are the same in the case of Waves... it's the WAVESHELL that actually communicates the with the appropriate software. The RTAS Waveshell probably does 32 float in either platform and then just communicates back the appropriate data to the ProTools system...

[Matt Chan]

thanks for everyone's replies...

i wound up putting it back into the trim plugin. the editor was kind enough to extend all his automation beyond the region boundaries and didn't use volume automation to fix transients....

but i'm testing the fx side of things, running with the sound editor's automation. i put all my tracks into trim mode and i also have them grouped into VCAs and i am getting unreliable playback of automation. i'll play it back once and it the level will jump down and i play it back another time and it is fine. it sucks!! coupled with the sluggishness of ExpansionHD, i feel like i'm back on a g4 in OS9...

i'll have to have a more "scientific" look at this trim vs. vca. automation when i have a chance. until then i'm avoiding staying in trim mode for anything but broad strokes.

[potatohead]

Any chance someone can confirm this RTAS vs. TDM plugin architecture question? With sufficient host CPU muscle, why not use RTAS plugins instead of TDM for headroom-munching insert tasks? This would save lots of gainstage scrutiny and put the ears back into the final QC position a la floating point mixing desks such as the DFC.

Or am I just being (yet again) naively optomistic?

Phil

[citysoundman]

Interesting thread! Could someone please clarify what is the specific problem(s) with using the trim plugin for automation? (I see that latency is mentioned, but ADC should take care of this...no?) I use it regularly for secondary volume automation, but after reading this thread I'm trying to recall if I have had problems with inconsistent playback (automation not happening where I expect it based on break points...that kind of thing).

And is there some problem with using volume trim?? Not sure, but now I'm confused on these two points...

Thanks in advance.

[Richard Fairbanks]

ADC has nothing to do with this problem. The problem is that many, many editors tend to adjust playback volume on a region-by-region basis. They use the Trim tool to grab an automation graph. Pro Tools defaults to adjust the entire region if you haven't selected anything else and places new breakpoints at the region's head and tail. Volume automation gets very high priority during playback, and Pro Tools is able to keep close to sample-accuracy of these sudden changes. (NO automation is actually sample accurate.) Most plugin automation (maybe ALL plugin automation) does not get such high priority and is updated less frequently. Plugins are slower to react to changes, so Trim volume changes are less timely than regular volume changes. This becomes a very audible problem if you have instantaneous volume changes at a region's head, and want to copy those onto a plugin's volume control. Suddenly you will hear the volume change many samples or milliseconds after the audio has begun. This may not be audible if there is a fade up on the region but is usually obvious otherwise. It is also inconsistent behavior, so that the plugin may react at a slightly different point each playback. The best solution is to extend the volume breakpoints just ahead or behind of the region, a video frame's worth is almost always enough, so a plugin will have time to react to a new setting before the audio actually happens. All editors I have worked with do not take the time to do this. It becomes a problem during mixdown.

When I edit I always select a wider area than the actual region, so that any sudden automation move happens before and after the actual region, and when I move those regions off of one track to another, I mark a larger area than the region so that the automation is carried along properly. It takes more time to do it right, but I NEVER have the problems people are complaining about.

A similar problem happens if you draw a quick move to fix a sibilance or transient, for instance. Sometimes, if your automation move is very close to the problem, the plugin may not be able to react in time. You have to start the move a bit earlier and let it remain in place longer. Usually, I've been able to do this without it sounding objectionable. It is best to avoid using plugin automation to fix these kinds of things.