When Avid released Pro Tools 10 they took the opportunity to consolidate the different RTAS TimeAdjuster plug-ins into one AAX Time Adjuster plug-in (note the spelling change, this isn’t a typo). However with the release of Pro Tools 11 which no longer supports RTAS plug-ins a snag has popped up in some users workflows because Pro Tools considers the new Time Adjuster to be a different plug-in and so it doesn’t recognise the automation from the old plug-in. In this video we show you the problem and the workaround given to us by Simon Sherbourne from Avid UK.

This has come to the surface because prior to Pro Tools 10, some users started using the Time Adjuster plug-in as a Gain adjuster because it has 24dBs of gain unlike the Trim plug-in which has 12dBs. However the old plug-in has become part of the the normal workflow and has been embedded in template sessions. Obviously from here on using Clip Gain makes sense but thanks to Simon, users have a workaround to cover legacy sessions when opening them in Pro Tools 11.

Update

on 2013-08-06 11:29 by Mike Thornton

Andy Hagerman from Avid in Japan replied saying….

Just saw your video regarding the migration of automation from the old Time Adjuster family to the new single Time Adjuster plugin.  You mentioned that, though the gain can be easily pasted from the old plug to the new one while keeping the absolute values constant, the delay value itself doesn’t really translate.  You explained it well - what is being pasted is the position of the fader, which has a different absolute value in the new plug-in than it does in any of the previous version. Realizing that this is getting deep into geekdom, I wonder whether this might work:

1. Turn on Automatic delay compensation (the only plugin that isn’t compensated for is the Time-adjuster plugin.

2. In the +/- section of the delay compensation view of the mix window, enter a value that compensates for the differences in range.

I realize that there’s also the matter of the difference in the scale of the delay amount controls, but this might work in a large number of cases (where only one delay value is being used - the majority of cases in my experience). Great work as always, guys!

Thanks Andy - You make a good point about the delay being a single value. Thinking about it what about copying the automation across (yes the absolute value would be incorrect) and then use the Trim tool to adjust it to the new value, as the automation from the old plug-in still gives the correct value but it would only work for single ranges where as yours would be close even when there is some fluid automation.