Transition to AAX: A Real Programmer's Perspective

[DaveTremblay]

Originally Posted by OSXPCUser

Hi,
I have I few questions about the new AAX plugin file structure.
Does the AAX plugin have a .aax file extension and
is it stored in the same file directory as RTAS and TDM plugins
or is it .dpm ?

It is a completely new file format and lives in a new location. The extension is actually .aaxplugin and is a bundle on OSX and a similar type thing on Windows. Where they live is OS dependent, but on OSX, they are in Application Support/Avid/Audio/Plug-ins. I don't have my windows machine up at this moment, but is a similar modification to the path. Avid branded.

DPM files are still stored in their old location. Pro Tools will load from both directories and apply appropriate plug-in dominance rules to figure out which one shows up in the menus... Very much thought through dominance rules...

Dave

[DaveTremblay]

Originally Posted by LukeHoward

On the Mac, they're stored in /Library/Application Support/Avid/Audio/Plug-Ins, and the bundle extension is aaxplugin.

I should read the whole thread first. :) Thanks.

Dave

[DaveTremblay]

Originally Posted by daeron80

On Windows they're stored in the same folder as the dpms, and the extension is .giganticleapinsoundandspeedaaxpluginsothere. j/k.

Wish we would have thought of that... :)

Dave

[DaveTremblay]

Originally Posted by pcmusicpro

"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."

I would like to know exactly what RTAS/TDM and AAX can do that VST can´t.

Sure.

VST doesn't have the ability to build the processing part of the algorithm to live on embedded DSPs. VST3 is pretty nice actually, and I wouldn't trash it for a native only plug-in spec, but we make more than just Pro Tools. And obviously more than just native engines, even within Pro Tools.

To accomplish this aspect of AAX, we had to strictly separate the processing code from the data/GUI and set up a communication layer that would work, not only across processes, but across processor architectures. I would assert that this is not feasible with VST.

We also separated our GUI from our data model (parameters and stuff) in AAX differently from VST and AU for more future looking reasons.

The bottom line is that we're trying to build an architecture that meets our pressing needs today (HDX, 64 bit), but also is architected for some future products. It's easy to talk about the requirements for HDX and 64 bit, not so much the future stuff, so I'll leave it at that.

Does that answer your question? I'd be happy to dig into more specifics if necessary.

Dave

[DaveTremblay]

Originally Posted by John_Toolbox

Integration with their dsp chips and with pro tools itself come to mind. I'm guessing that converting all of the stock protools plugins to aax and keeping them somewhat backwards compatible was a lot less work than completely rewriting them as vst, and then trying to get them to work with the hdx hardware.

Thanks for jumping in. Your guesses are mostly correct with the DSP and Pro Tools integration features, but I wanted to add a little bit to the last point. Our plug-ins were pretty old code. Good sounding, no doubt, but old code. We basically rewrote all of our plug-ins. And it would have been about the same to go either to VST or AAX, but VST did not fill our product roadmap requirements.

And just to be clear, AAX plug-ins are not backwards compatible. They will load on PT10 and later, but they won't load on PT9. We looked at doing that at one point (for AAX Native), but it was going to be a significant amount of work and likely cause a bunch of bugs, which is the last thing our customers need...

We were able to keep RTAS and TDM compatible with PT10. Forwards compatible? Kind of a pain actually, but an absolute requirement for all of you guys.

Dave

[sunburst79]

Old PT code took advantage of SSE, Any chance AAX will take advantage of AVX?

[DaveTremblay]

Originally Posted by sunburst79

Old PT code took advantage of SSE, Any chance AAX will take advantage of AVX?

Good question. I don't know about PT, in general, but in many places we use the Intel IPP libraries which are often optimized for the most up-to-date chip features. Depends on the version we're using. If we're not fully supporting that now, I suspect it would just be a matter of time.

Dave

[OSXPCUser]

Originally Posted by DaveTremblay

It is a completely new file format and lives in a new location. The extension is actually .aaxplugin and is a bundle on OSX and a similar type thing on Windows. Where they live is OS dependent, but on OSX, they are in Application Support/Avid/Audio/Plug-ins. I don't have my windows machine up at this moment, but is a similar modification to the path. Avid branded.

DPM files are still stored in their old location. Pro Tools will load from both directories and apply appropriate plug-in dominance rules to figure out which one shows up in the menus... Very much thought through dominance rules...

Dave

@ LukeHoward & daeron80
Thanks for the info
and @ DaveTremblay
Thanks for your confirmation I was really hoping you or someone from Avid would answer. so Thanks
I would still hope you could confirm the Windows file path.

Don

[John_Toolbox]

Originally Posted by DaveTremblay

Thanks for jumping in. Your guesses are mostly correct with the DSP and Pro Tools integration features, but I wanted to add a little bit to the last point. Our plug-ins were pretty old code. Good sounding, no doubt, but old code. We basically rewrote all of our plug-ins. And it would have been about the same to go either to VST or AAX, but VST did not fill our product roadmap requirements.

And just to be clear, AAX plug-ins are not backwards compatible. They will load on PT10 and later, but they won't load on PT9. We looked at doing that at one point (for AAX Native), but it was going to be a significant amount of work and likely cause a bunch of bugs, which is the last thing our customers need...

We were able to keep RTAS and TDM compatible with PT10. Forwards compatible? Kind of a pain actually, but an absolute requirement for all of you guys.

Dave

How about plugin settings?
If I create a session in PT10 and save it in the PT9 format, with aax plugin like 1 band EQ, will the PT9 session be able to know that I changed the settings on the EQ and recall them in the rtas version of the same plugin? That's really what I was trying to say, compatibility of plugin settings.

[DaveTremblay]

Originally Posted by John_Toolbox

How about plugin settings?
If I create a session in PT10 and save it in the PT9 format, with aax plugin like 1 band EQ, will the PT9 session be able to know that I changed the settings on the EQ and recall them in the rtas version of the same plugin? That's really what I was trying to say, compatibility of plugin settings.

Plug-in settings are stored in the same location as PT9. We considered changing it (actually did for a while), but it turns out that moving this is quite a bit more complicated. For instance, if you are running PT10 HD on a TDM system and have your older (and newer) plug-ins installed, the TDM version is still available and the AAX Native version is available. To make sure that your plug-in settings can be shared, even when doing something as simple as swapping from Native to DSP, is to keep the plug-in settings directory exactly where it is. Maybe in 64 bit, we can sort all this stuff for good, but for now any changes there was just a plain bad user experience.

Dave