A Programmer's Perspective on the AAX Transition + Q&A

[DaveTremblay]

Originally Posted by BobbyDazzler

What are the chances of a TDM wrapper for future HDX?

I'm not sure exactly what you mean by that, but I will say that the way our legacy TDM plug-ins worked and the AAX DSP plug-ins work is very different. It seems unlikely that we'd be able to resolve those differences in any sort of wrapper without an absolutely heroic effort and some compromises to features and performance.

Dave

[DaveTremblay]

Originally Posted by sunburst79

I think that means NO.

Would RTAS fare any better seeing as it wasn't compiled to DSP specific language first? Is there a potential the someone like FXSpansion could follow up the VST2RTAs Wrapper with a AAX2RTAS Wrapper? I can't imagine you would want to use it when you had AAX available but there might be useful opening legacy sessions containing non AAX plugs.

Possibly, but RTAS is supported directly right now. If a third party wanted to write a 32 bit to 64 bit RTAS to AAX Bridge, I guess they might be able to but all bridges come with some significant tradeoffs...

Dave

[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 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

[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

[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

[DaveTremblay]

Originally Posted by NuBus

So a RTAS version of Kontakt is more powerful and flexible than a VST version???

And the same for Waves or any other plug-in for that matter???

How so? Or should I just take his word for it??

I guess I need the words Power and Flexible defined to me???

What can you do with a RTAS that you can't do with a VST to make it more powerful and Flexible???

Sorry, there was a misunderstanding. AAX covers more than just RTAS. It is a RTAS, TDM, and Audiosuite replacement. The flexibility that is easy to explain at this point is that AAX plug-ins can run on embedded DSP cards and VST cannot. You'll likely see some more examples of our designed flexibility in the future, but just comparing AAX Native to VST isn't a complete picture.

There are some Pro Tools and control surface integration features that we have added to AAX that don't exist for VST, but they likely aren't something you'd see in Kontakt.

Dave

[DaveTremblay]

Originally Posted by corp

Meaning if they use all AAX plugs nothing transfers?

Does this statement hold water:

There has been some confusion here so let me try to clarify.

1) AAX Plug-ins will not load on PT9 and earlier. Just to be clear.

2) Presets, Automation data, etc from an RTAS or TDM plug-in will convert to the equivalent AAX plug-in and be compatible if you load that session in PT10 with AAX plug-ins. (If there is no AAX plug-in, the legacy versions will be used)

3) Presets, Automation data, etc from an AAX Native/DSP plug-in in a PT10 session will load into PT9 (using save as) and load the legacy RTAS or TDM plug-in.

I can try to explain this in a little more detail. When you instantiate a plug-in, Pro Tools knows about that type of plug-in by a unique set of identifiers. We kept those unique identifiers equivalent for AAX, so a plug-in developer can reuse them for their AAX plug-in. If those identifiers are identical between the AAX and Legacy versions of a plug-in, Pro Tools doesn't know the difference. (up high in the app) When doing PT10, we wrote a bunch of extra code to allow AAX plug-ins to "dominate". In the past if you had identical unique identifiers between two plug-ins, you'd get a Pro Tools error and it would move one. With the advent of AAX, we now allow this as long as one is legacy and one is AAX. And we make sure that AAX plug-ins are used if available. This is actually pretty complicated code, but we've tested it pretty well. In addition to this, we've kept much of the old data storage (presets, automation data, etc) mechanisms in place to guarantee session compatibility moving forwards (and backwards). If there are problems with this, we'll attempt to fix them or work with the plug-in companies to straighten the issues out, but right now it works pretty darn well.

Dave

[DaveTremblay]

Originally Posted by corp

The bottom line is if a client brings me a session that has all AAX plugs and I'm still TDM there's no converted transfer for plugs even if they save early version?

No. If they create a session using AAX plug-ins that have older RTAS and TDM versions, the plug-ins will load as RTAS or TDM.

For example, if I have an AAX DSP EQ3 instantiated on a track and I save that session and load it on PT 10 HD (not HDX), it will load as EQ3 TDM. If I save the session for PT9, it will also load as EQ3 TDM.

If I have an AAX Native EQ3 instantiated on a track and I save the session for PT9, it will load as EQ3 RTAS.

If I then hand that session back, the plug-ins will instantiate as their original AAX versions. This is all transparent to the user.

Dave