Any AAX Juce ports using Juce pre-2.0?

Hi all,

I’ve been following the AAX thread with interest, and have also noticed that a fair number of Juce developers have announced AAX support. For any plugin folks that successfully have AAX working, are you using the Juce AAX wrapper? Or did you roll your own, or just compile directly to AAX with a Juce GUI? Are you using the current 2.x tip, or an older version of Juce?


Sean Costello

You’ll certainly need the tip - there’s little chance of getting it working with older code.

I have inside knowledge of numerous shipping AAX/JUCE plugs, and none of them use the AAX wrapper. In fact, none of them is on the tip. Nearly all are using 1.53. At least one is using 2.0.18.

This is what I suspected. So, are these plugins just using Juce for the GUI?

Sean Costello

It looks like most of the people in the Avid dev forum are using Juce 1.53. Does the current Juce 2.0.x AAX wrapper work for people now?

Sean Costello

Not for me, but I am a noob with C++. I still hope to find a working solution for this.

Edit: I have the Mac version compiled now and am doing test… :slight_smile:


I can build my plugin as AAX and RTAS and both load… the AAX version has certain functionality which doesn’t work (respond to incoming MIDI for example)… and the AAX version crashes when you quit Pro Tools… but these are known issues… and things I’ll have to battle when the RTAS version is complete and I have the time to dig into the AAX code. Jules has indicated he doesn’t currently have time to work on the AAX code… and was hoping the user base would jump in to help out.

There’s an example using JUCE just for the UI in the SDK.

It would be great if anyone who has made any changes to improve the AAX code posted them so we’re not all reinventing the wheel.



Afaik the AAX wrapper is currently missing just parameters (for automation/controllers) and MIDI.

I would really really really appreciate it if someone who has already done that work (on either old Juce version or current) to share their wrapper with me and I’ll work to integrate their changes with the current Juce and send it to Jules so we could all use it.
I already contributed patches for save/load and playhead, but it would certainly save time, bugs, and effort if someone already did it…

Then we could all use the same blessed, fully featured, and superbly maintained wrapper! :slight_smile:

Cheers! Yair

Hi Yair

Do you not get the crash when you quit Pro Tools after running a JUCE AAX plugin?



Nope, works fine for me. Only tested it on OS X 10.6 so far though.

I can reproduce the problem 100% of the time, here the steps:

(Pro Tools 10.3.3, on MacOS X 10.8.2)

  1. Create a blank session
  2. Create a new track inside that with some audio content
  3. Insert the plug-in into the track
  4. Close the plug-in GUI (I thought it could be related to that, but turns out it makes no difference)
  5. Choose “Quit from Pro Tools” from the menu and tell not to save the track


This always results in the Pro Tools application lingering indefinetely open in the dock, even if all of its windows have been destroyed.

Interestingly enough, I can avoid this “hanging” (i.e. Pro Tools quits smoothly) by doing one of these between point 4 and 5 above:

a) remove the plug-in from the track
b) choose to explicitly close the session from the File menu before quitting Pro Tools

The feeling is that everything works fine when the plug-in is unloaded explicitly before closing Pro Tools, but it hangs if Pro Tools itself should unload it during shutdown. Does this ring some bell?

(this behaviour has been reproduced before and after the changes to the tip that got rid of the PluginInstanceInfo struct, so I think we can assume it is unrelated to that change)

Sounds like the same problem that happens in every other host and format when it closes the UI and immediately unloads the plugin from memory without allowing the message loop to run. Usually the problem is that there’s an NSWindow hanging around that doesn’t get chance to close cleanly. As discussed on lots of other threads, there’s no real fix from the plugin’s side - the best that can be done is to make the plugin briefly run a message loop before closing, but that’s dangerous in other ways.

No, I’ve tested this and this can’t be the case: the UI of the plug-in is not even shown.

I’ve even bypassed the creation of the UI altogether by returning nullptr in the Create() that creates the UI. The problem is in the processor part, not the UI

[quote=“yairadix”]Afaik the AAX wrapper is currently missing just parameters (for automation/controllers) and MIDI.

I would really really really appreciate it if someone who has already done that work[/quote]

I’m working on the automation part these days, hopefully next week I’ll have something in that area.

Has someone done any progress regarding the “hanging” problem upon Pro Tools exit?

jules, here’s my proposal to implement parameter automation in AAX in current JUCE tip

seems to work fine with AAX SDK 1.5.0 and Pro Tools 10.3.3 on Mac, haven’t had time to test it on Windows

Great stuff! Thanks as always - I’ll do some merging asap…

[quote=“yfede”]jules, here’s my proposal to implement parameter automation in AAX in current JUCE tip

seems to work fine with AAX SDK 1.5.0 and Pro Tools 10.3.3 on Mac, haven’t had time to test it on Windows[/quote]


Tried it here on Mac and Windows and it worked well in Windows (with one small issue) but didn’t work for me on Mac. I’m trying it using the juce demo plugin to rule out that I’m doing stuff wrong on my side.

On Mac, tested on Pro Tools 10.3.2, then upgraded it to 10.3.3 and it still didn’t work. The parameters appear, but the plugin simply ignores automations and automation recording doesn’t work as well. Looking into it…

In Windows (using Pro Tools 10.3.2), it works well except that when adding a new plugin instance, the parameters get set to zero.
To fix that I’ve changed in the line:

AAX_IParameter* parameter
    = new AAX_CParameter<float> (IndexAsParamID (parameterIndex),
                                 audioProcessor.getParameterName (parameterIndex).toUTF8().getAddress(),
                                 AAX_CLinearTaperDelegate<float, 0>(),
                                 AAX_CNumberDisplayDelegate<float, 3>(),

from the default value “0.0f” to:

audioProcessor.getParameter (parameterIndex)

thx! Yair

Good call, thanks.

On the issue of RTAS <-> AAX compatibility (ability to save a session using RTAS and then loading it with AAX, or vice-versa):

It currently doesn’t seem to work.
When saving with RTAS, then removing the RTAS and putting the AAX plugin in place, and then reloading in PT, PT says that the plug-in is missing…

One thing that seems wrong: it looks like the AAX_eProperty_PlugInID_Native property should be consistent with the RTAS plugin’s “type id”, but I tried doing that and it still does not work for me…

Did anyone already solve this and can give us all some pointers? :slight_smile:

Cheers! Yair

Oops, I’ve had a human error in testing and tested the wrong code, silly me…

So the new parameters code actually works great!

The RTAS-AAX compatability issue is real though, but the fix I mention does actually does solve it! See

Thanks! Yair