New Pro Tools plugin format: AAX


#1

Avid just announced AAX. Apparently the same code can now be compiled to native and HD (with the new HD being called HDX).

I know I mentioned this in another thread, but this is important news for a lot of us Juce users.

Sean Costello


#2

It seems that there is a Juce example in PT 10 SDK.
Did you try it?


#3

We built a couple of AAX plugins using the Juce class provided by Avid. (Avid gave us access to the SDK last summer.) It works pretty well although there are some issues.

They might have fixed this now, but in the AAX_CEffectGUI_Juce.mm class (OSX only) you have to add this line before the import of Cocoa, because they made the SDK using an older version of Juce.
#define Point CarbonDummyPointName // (workaround to avoid definition of “Point” by old Carbon headers)

There also seems to be other minor issues like Juce based plugins retain the focus even when you click on other plugins and so on.

The biggest problem though is trying to figure out how to reuse your existing Juce based code that you’re using to build AUs or VSTs without things becoming a mess. We ended up creating our AudioProcessor subclass as an AAX private data object and delegating the audio processing and parameter handling code to this class. This worked reasonably well although there were some cases where from some points in the code you needed to access the AudioProcessor subclass but there wasn’t any way to get to your private data from that context. But there are a couple of ways around that sort of a problem, and you just have to choose which one you dislike least…

But speaking of reusing your existing Juce based code, Jules have you had a chance to look at the AAX SDKs yourself and have you given any thought as to whether the AudioProcessor and Introjucer could be expanded to support AAX? We’ve been thinking about making another attempt to improve the code reuse between our AAX and our AU/VST code, and it would be good to know what changes you might have in mind yourself.


#4

[quote=“ke20”]It seems that there is a Juce example in PT 10 SDK.
Did you try it?[/quote]

I need to try it again, setting up the Juce paths and such. Right now, I’m focusing on an upcoming new plugin, as well as a few updates for existing plugins, so I’ll check out AAX seriously after this work is done. Probably the December timeframe. I figure PT11 won’t be out for awhile, so I have time to port. Apparently RTAS and AAX have similar performance in PT10.

Sean Costello


#5

I understand. This is the same thing for me :slight_smile:


#6

I reiterate: Jules have you had a chance to look at the AAX SDKs yourself and have you given any thought as to whether the AudioProcessor and Introjucer could be expanded to support AAX? We’ve been thinking about making another attempt to improve the code reuse between our AAX and our AU/VST code, and it would be good to know what changes you might have in mind yourself.


#7

Yes, of course it should be expanded to handle AAX, and I’m sure that’s straightforward enough, but I just haven’t had chance to take a close look at it yet.


#8

Has there been any forward motion on AAX?


#9

Listening to this thread …


#10

Same here. Busy doing a lot of R&D and we’ll probably just wait for a Juce implementation for AAX. I figure it will be supported fully in Juce by the time it really matters (Pro Tools 11.) 8)


#11

Same here. Busy doing a lot of R&D and we’ll probably just wait for a Juce implementation for AAX. I figure it will be supported fully in Juce by the time it really matters (Pro Tools 11.) 8)[/quote]

Any news on this? Jules, do you have PT10 up and running?

Sean Costello


#12

No, I’m totally in the android/introjucer/modules zone right now. No spare brain capacity for audio, but when I do get back to this I’m sure you’ll hear about it.


#13

No, I’m totally in the android/introjucer/modules zone right now. No spare brain capacity for audio, but when I do get back to this I’m sure you’ll hear about it.[/quote]

I appreciate the update!

FYI, Apple is dropping 32 bit support with OS X Mountain Lion this summer. This means that Avid will need to get Pro Tools 11 out the door in time, or there will be NO Pro Tools for Mac. This also means that all of us here who develop for PT will need to have AAX plugins ready in time, since RTAS cannot support 64 bit. Combine that with the XCode 4.3 headaches, and it’s a really fun time to be an audio plugin developer right now. :?


#14

I can certain second Soilworker’s comments. I’ve given thought to writing my own wrapper, but the AAX API is downright scary.


#15

Thirded. There are a fair number of folks that invested in Juce for the RTAS support, and since Avid is forcing our hand on AAX, getting Juce support for AAX is CRITICAL. This isn’t really a “nice-to-have” for plugin developers, it is a must have.

Sean Costello


#16

[quote=“valhallasound”][/quote]
Thirded. There are a fair number of folks that invested in Juce for the RTAS support, and since Avid is forcing our hand on AAX, getting Juce support for AAX is CRITICAL. This isn’t really a “nice-to-have” for plugin developers, it is a must have.[/quote]
Exactly, and also time is running ! Because RTAS won’t run in 64 bits…

Salvator


#17

+1


#18

bump!


#19

I could buy Juce one more time just to get AAX support. I think a lot of users need this update.


#20

Moreover, new MAC OS will be released in a few months, and as far as I know, 32 bit support will be dropped.
That means that a lot of users will be forced to use new version of ProTools (wich will support only AAX plugins)

That is not a minor problem, because I (and many other commercial users I think) bought Juce especially for plugin development.
I can live without that (multiple time promised) sidechain support, but obviously I can’t live without AAX support.

Jules, can you please provide us clear plans on the subject?
Because if you will not implement this in a 1-2 months, then we should start serching for expirienced Juce/PT developer and pay money for AAX support.

Please, we need your answer, that is really critical for us.