Avid Pro Audio Community

Avid Pro Audio Community

How to Join & Post  •  Community Terms of Use  •  Help Us Help You

Knowledge Base Search  •  Community Search  •  Additional Resources


Avid Home Page

Go Back   Avid Pro Audio Community > Legacy Products > Pro Tools 10 Discussion

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 10-25-2011, 08:53 AM
reichman's Avatar
reichman reichman is offline
Member
 
Join Date: Aug 2000
Location: New York
Posts: 1,807
Default Transition to AAX: A Real Programmer's Perspective

This was posted on the Daw-Mac list recently. Frank Filipanits generously gave me permission to share it here. I think his (2) posts are required reading for everyone:

Quote:
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").

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.

-Frank

Frank Filipanits
Cool Stuff Labs, Incorporated
Reply With Quote
  #2  
Old 10-25-2011, 08:54 AM
reichman's Avatar
reichman reichman is offline
Member
 
Join Date: Aug 2000
Location: New York
Posts: 1,807
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Posted by: "Nathaniel Reichman" <> on Sun Oct 23, 2011 6:51 am (PDT)
I was at AES on Friday, and despite some controversy over high upgrade prices, and developers dragging their feet, it was completely evident that Avid has put a tremendous effort into Pro Tools 10. I used systems there, and they were snappy and powerful. The plug-in menus on the demo rig showed that there are separate "DSP" and "Native" menus, similar to RTAS and TDM now. However, Avid product specialists where quick to point out that the underlying sonic code is identical, so hopefully developers won't have a hard time making both versions of the new AAX plug-ins (would love to hear from Frank Filipanitis here).
Quote:
Posted by: "Ben Cox" <> on Sun Oct 23, 2011 6:56 am (PDT)
What I want to know is, does it also make it so that developers won't have a hard time making plugins that only work in Native or DSP modes, and thus charging separately for them? I'd love it if _all_ AAX plugins would run in Native or DSP, and it was not possible for a plugin vendor to charge separately for DSP vs. Native.
Quote:
RTAS and TDM require two completely separate implementations due to the fundamental differences in architecture; RTAS is written in C or C++ in a floating-point environment, TDM is written in 56k assembly language in a fixed-point environment. While the GUI and "glue" code could be shared between the two, the actual processing code had to be written completely separately for TDM and RTAS. This made ensuring bit-for-bit matching and synchronization of changes difficult.

HDX changes the DSP hardware to a floating-point architecture and AAX enables the possibility of writing a single implementation of the algorithm in C that compiles to both the native and hardware-accelerated versions. Note I said "enables the possibility". The realities of writing an algorithm for the constrained architecture and feature set of the HDX hardware and TI DSP makes it significantly harder than simply writing a plug-in to run on the host. There are many differences to factor, ranging from the straightforward (buffer size) to the complex (subtle differences in mathematical operations btw Intel and TI). And while simple algorithms can indeed run identical code on Native and DSP, many will still require some conditional code that is different on Native vs. DSP.

In general however, it should be the case that if the algorithm runs as AAX DSP it can run as AAX Native with little additional effort (though not necessarily optimized for speed). The converse, however, is not true... while it is MUCH more straightforward to adapt an AAX Native algorithm to AAX DSP than it was to adapt RTAS to TDM, there is still a considerable amount of effort and additional testing involved. So I expect we may see some companies elect to do plugs that run as AAX Native but not AAX DSP, at least initially.

I hope that we won't see stratification in the market, with different price points for AAX Native and AAX DSP+Native; I think it is much simpler to have a single SKU and pricepoint for both. But the fact remains that making a plug run on the DSP requires additional cost, effort, and support -- so it either gets baked into the price of a unified (DSP+Native) plug, or companies can attempt to recoup that additional cost only from those customers using the DSP side, while keeping the Native side a little cheaper.

I should also mention that attaining bit-for-bit matching between Native and DSP may no longer be practical for many algorithms.... expect to see manufacturers changing that bullet point to "matches to -96 dB" or "difference below -110dB" or something to that effect.

One last note regarding "developers dragging their feet"... the AAX spec was rolled out on a VERY aggressive schedule. Some vendors were able to refactor their plugs for AAX quickly, others were not. Avid provided a tremendous amount of support and encouragement to get as many third-parties ready for the roll-out as possible, but the amount of effort required varies tremendously from plug-in to plug-in. AAX also obsoleted a graphics framework used by some plug-ins, so vendors whose products were based on that not only have to refactor the processing code for HDX but also completely redo the UI code. Some companies are also better positioned to endure the painful parts of being on the bleeding edge, while others need to wait for things to settle out and stabilize before committing resources.

Again, while it is going to be a painful transition for many people -- users and developers alike -- I do believe that this is a good and necessary move for the future.

-Frank

Frank Filipanits
Cool Stuff Labs, Incorporated
Reply With Quote
  #3  
Old 10-25-2011, 09:03 AM
Bob Olhsson Bob Olhsson is offline
Member
 
Join Date: Jan 1970
Location: Songwriter Gulch, Nashville, TN
Posts: 3,139
Default Re: Transition to AAX: A Real Programmer's Perspective

This really ought to be a sticky!
__________________
Bob's room 615 562-4346
Georgetown Masters 615 254-3233
Interview
Artists are the gatekeepers of truth! - Paul Robeson
Reply With Quote
  #4  
Old 10-25-2011, 09:27 AM
TOM@METRO's Avatar
TOM@METRO TOM@METRO is offline
Moderator
 
Join Date: Apr 2006
Location: Los Angeles
Posts: 16,255
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by Bob Olhsson View Post
This really ought to be a sticky!
I fully agree. This puts a healing perspective on the confusion and misunderstandings plaguing this forum.
__________________
~ tom thomas

Formerly hobotom

Pro Tools 12~HDX~HDN
Studio One 3.3~DP9
HD Omni~192 I/O
MOTU 24 I/O
Windows 10
Intel Hexcore i7, SSD
Gigabyte GA-X79-UD3
Ampex MM1200 2" 24 trk tape
Outboard: UREI, Eventide, Lexicon, Yamaha, TC Electronics, Orban, ART, EchoAudio, Dolby, Hughes, API, Neve, Audio Arts, BBE, Aphex, Berringer, MOTU, dbx, Allison, etc.

www.metrostudios.com
Reply With Quote
  #5  
Old 10-25-2011, 09:51 AM
originalscottyg originalscottyg is offline
Member
 
Join Date: Jan 2006
Location: Detroit
Posts: 357
Default Re: Transition to AAX: A Real Programmer's Perspective

+1

Quote:
Originally Posted by Bob Olhsson View Post
This really ought to be a sticky!
__________________
Scott Gatteño
Yessian
Reply With Quote
  #6  
Old 10-25-2011, 09:58 AM
bashville bashville is offline
Member
 
Join Date: Apr 2004
Location: New York
Posts: 1,099
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by corp View Post
Very good post.......

Would Waves be one that is dragging there feet on AAX.........

I also have a feeling that AAX using dsp version that cause companies to take more time to develope will push cost onto the user......... business as usual...
Funny this post somehow prompts an immediate "attack Waves" response, when if anything it demonstrates the difficulties plug manufacturers are going to have waltzing around this thing. Mercury has what, 130 plugins? Maybe 7-10 times more than most other companies? It's been two business days post-AES and Waves doesn't yet have a big free package wrapped up in a bow for everybody to download---!

It would be nice, though, to see some statement or reaction from Waves or McDSP or whoever. Like "we just found out about this, preparing a statement" maybe.

I remember when Logic made the big plug-in changeover. They told nobody until the big announcement. So BFD basically said it was news to them also, we're all on the same learning curve. Possibly ProTools held this close to their chest as well....
__________________
HD-Native, PT12, 192, 3.2 Quad MacPro 5,1, 16 Gig, Sierra
Reply With Quote
  #7  
Old 10-25-2011, 09:59 AM
Farmer Dave Farmer Dave is offline
Member
 
Join Date: Jan 1999
Location: Marin County, CA USA
Posts: 977
Smile Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by Bob Olhsson View Post
This really ought to be a sticky!
+1

Thanks for posting this. I share this perspective on the product changes, though I'm not a developer.
Reply With Quote
  #8  
Old 10-25-2011, 10:00 AM
Darryl Ramm Darryl Ramm is offline
Member
 
Join Date: Nov 2010
Location: USA
Posts: 11,294
Default

Hire that man to run Avid Marketing!

Darryl
Reply With Quote
  #9  
Old 10-25-2011, 10:11 AM
John_Toolbox's Avatar
John_Toolbox John_Toolbox is offline
Moderator
 
Join Date: Feb 2004
Location: Minneapolis
Posts: 5,170
Default Re: Transition to AAX: A Real Programmer's Perspective

Finally, a thread about PT10 that's not a complete waste of time to read!

A+++++++++++++++
__________________
- John

If a MIDI event triggers a sample of a tree falling and there's no one there to hear it, does it make a sound?
Reply With Quote
  #10  
Old 10-25-2011, 10:13 AM
mike connelly mike connelly is offline
Member
 
Join Date: Jan 2000
Location: chicago
Posts: 1,317
Default Re: Transition to AAX: A Real Programmer's Perspective

Didn't Frank used to work at digi in the mid to late nineties? I thought I remembered seeing his name in the Pro Tools credits back in the day.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
A Programmer's Perspective on the AAX Transition + Q&A reichman AAX Plug-ins 32 07-16-2012 02:25 PM
perspective control 24 youbringmesuffering ICON & C|24 10 01-31-2010 10:27 AM
PC to Mac....looking for a little perspective Studio66 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 15 10-09-2008 03:50 PM
Reason / PTLE (different perspective) basis3708 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 14 09-06-2001 07:58 AM
Female perspective Doc 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 6 07-16-2001 09:21 AM


All times are GMT -7. The time now is 11:46 PM.


Powered by: vBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Limited. Forum Hosted By: URLJet.com