The debates about the industry standard DAW has never been so vicious. Pro Tools 10 is probably the latest release that supports RTAS and TDM. The new futureproof format is AAX (Avid Audio eXtension). The transition started, but we, users still don’t know many things about the upgrade paths, prices, etc. Many shallow observers think that Avid is playing a weird game with us, though the fact is: this is an absolutely necessary move. And in my opinion, Avid is in the 24th hour with this transition. There are many sort-of-right information floating around, but now we can face the truth.
This is posted on the duc, and I think it gives a more clear picture about this whole transition:
The post is written by Frank Filipanits. If someone doesn’t know who this man is, it’s enough to say: He is the authority in this topic, period!
I post it unaltered:
“There’s a lot of almost-correct or sort-of-right information floating around regarding AAX, RTAS, and TDM. I’d like to try to set the record straight about a few things.
Unified AAX architecture:
The AAX spec strives to unify development so that the same algorithm can run natively or with DSP hardware acceleration on the new “HDX” TI-based floating point DSP cards, but there will remain a distinction between AAX Native and AAX DSP, with some (mostly third party) plug-ins only supporting one or the other. While Avid appears to intend to offer all of their plugs in one version only that runs on both, it is quite possible to create a plug-in that is either AAX Native only, or AAX DSP only.
Bit depth vs. internal processing:
There seems to be much confusion regarding how bit widths apply to different aspects of plug-ins.
TDM passes audio around using a 24-bit fixed-point pipe. Internal processing can be 24 bits, 48 bits, 56 bits or more. I lost track of what the mixer uses but it is very, very large.
RTAS passes audio around using a 32-bit floating-point pipe. Internal processing can be 32 bits, 64 bits, 80 bits, or more. I don’t know what the native mix engine uses but again it’s very very large.
AAX also uses a 32-bit floating-point pipe to pass audio around, for both Native and DSP. Internal processing can be 32 bits, 64 bits, 80 bits, or more.
Application word size:
When folks talk about an OS or APPLICATION being 64-bit, what that refers to primarily is the maximum size of a memory pointer, which places limits on the maximum amount of memory an application can use. It has nothing to do with the size of the data streams, or how efficiently the CPU can handle 32 vs. 64 bit float operations. A 32-bit application is limited to directly addressing 4Gb of memory.
Whether a plug-in (or host) is “64-bit ready” or “runs as 64-bit” has nothing to do with the word size of the audio pipes between plug-ins, which may well remain 32-bit float. Even if the audio pipes between plug-ins are 64-bit, the internal calculations may still use 32 bit operations since they are considerably faster than 64-bit operations (regardless of whether the host app or plug-in is “32-bit” or “64-bit”).”
and another post from him:
“Why a whole new format?
When the TDM spec was written in the early 1990’s, the state of the art was 68000-based Quadras running System 7 and hard drives in the tens of Mb. It had provisions for black and white monitors. RTAS was added as a branch of that spec, and Windows compatibility was grafted in. Quite honestly, it is amazing how long that spec lasted — through the transition from 68k to PPC, NuBus to PCI, OS9 to OSX, PPC to Intel. But facing continuing aggressive evolution of OSX and fundamental structural incompatibilities with operation in a 64-bit host application environment (among other concerns), it was time to rewrite the plug-in spec to meet the needs and capabilities of today’s and tomorrow’s systems.
Some question why Avid didn’t simply adopt AU or VST — a few simple reasons are these: AU is a mac-only spec, and VST simply doesn’t have the power and flexibility to do everything RTAS/TDM and AAX are capable of.
Believe me, I am less than thrilled that the 17 years of expertise, techniques, tools, and libraries I built around the RTAS/TDM spec are now as useful as COBOL. But AAX was a necessary move on Avid’s part, and not one they took lightly.
Personally, I think it is remarkable that Avid made PT10 a transitional product – one that runs BOTH the old (RTAS/TDM) and new (AAX) formats (with the one limitation that TDM and AAX DSP can’t coexist simultaneously). It would have been much easier to simply make a clean break with the old.
“It’s just a scam to make more money”:
Some people seem to think third parties are dancing with delight at the opportunity to force people to repurchase their plugs in a new format — nothing could be further from the truth. This is a HUGE pain in the ass for third parties, and plug-in manufacturers are stuck between a rock and a hard place: they have to spend considerable money and effort to port their software to the new spec, because no one is going to continue to buy the old format. But on day one, the market size for the new format is exactly zero. And existing customers often expect to get the new version for free or close to it. It’s an unpopular, very costly exercise for third party companies.
It’s not unlike having an expectation that since you bought an 8-track of “Led Zep II” for $5 back in 1969, that Atlantic Records would have provided you over the years a new copy — at no cost to you — in LP format, then cassette, then CD, then DVD-Audio, then mp3, then SACD, then Blu-Ray….
So take a deep breath. Remember that the TDM//RTAS system you have today works just as well and is just as capable as it was last week, and no one is going to force you to stop using it. PT10+ and AAX have some real advantages moving forward, and when those advantages overcome the cost disadvantages for you, bite the bullet and upgrade. Just like you did going from 68k to PPC, or NuBus to PCI, or OS9 to OSX. And give your plug-in companies the benefit of the doubt; this change is hard and expensive for them too.
Cool Stuff Labs, Incorporated”
I don’t know anyone else who could gave us a more concise, informative explanations about this transition. Thanks Frank!