FYI, I’ve just checked in a version where AAX now has functional audio and GUI. It’s far from finished because parameters aren’t implemented, but any contributions welcome!
(BTW, I know it leaks objects when you quit, I’ve yet to figure out a way to make it clean up properly)
Just compiled and run a test AAX plugin… no GUI and as expected leaking objects on quit… Will see if I can see why the GUI isn’t appearing…
The RTAS version runs fine.
JUCE v2.0.24, OSX
Set breakpoints in all the AAX wrapper class functions and so far not hitting any…
Cheers,
Rail
Well, the GUI works for me - were you trying the juce demo plugin, or your own?
My own… I’ll try the demo and let you know.
Cheers,
Rail
Yeah the demo works but my plugin the xxxxxAudioProcessorEditor::paint method never gets called… the constructor is executed fine which should trigger the Component to repaint() with the addAndMakeVisible()'s… The RTAS version works perfectly… I’ve tried adding a setVisible(true) in the constructor but that didn’t trigger a repaint…
Will keep debugging…
Cheers,
Rail
Do you give your component a non-zero size in its constructor?
The two formats have absolutely nothing in common, so it’s a waste of time looking at RTAS for inspiration!
Yes:
#define MAINWINWIDTH 960
#define MAINWINHEIGHT 610
#define SCROLLBARHEIGHT 15
setSize (MAINWINWIDTH, MAINWINHEIGHT+SCROLLBARHEIGHT+5);
Hmm… I thought that the function:
AudioProcessorEditor* JuceDemoPluginAudioProcessor::createEditor()
is common to both versions… createEditor creates a new class object:
new JuceDemoPluginAudioProcessorEditor (this);
which creates an object of the same class (JuceDemoPluginAudioProcessorEditor) for both the AAX and RTAS versions… so if the RTAS version works surely the AAX version should as well… or am I missing something fundamental?
Cheers,
Rail
Well obviously your code is the same for all platforms, but the wrapper code isn’t!
Well yeah 
What I was getting at was that my editor class definition was common… I’m trying to trace why the JuceAAX_GUI isn’t working with my Editor Component class… originally figured that if it worked with the RTAS wrapper it should be okay with the AAX wrapper… my Editor class isn’t all that different from the demo (less children components but it has a Viewport with a single Component which has additional children components)… I’ll keep hammering at it.
Thanks,
Rail
When closing ProTools (version 10.3.3) on MacOS X (10.8.2) with the current JUCE tip I’m getting some leak assertions upon destruction of PluginInstanceInfo and its MidiBuffer and Array <float*> members.
This is happening because the memory where PluginInstanceInfo is stored is owned by the host and initialized with a “placed” new in ResetFieldData, and there is no explicit destruction of the members. The host simply deallocates that block of memory upon unloading the plugin.
So, instead of storing that MemoryBuffer and Array as members of PluginInstanceInfo, I’d move them into JuceAAX_Parameters and store in PluginInstanceInfo only their reference, the same way it is currently done for the AudioProcessor.
For the same reason, PluginInstanceInfo should be only JUCE_DECLARE_NON_COPYABLE instead of JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR
Here is the patch as I’ve implemented it: https://github.com/yfede/JUCE/commit/8fc162ecc277fbefb331721d61633fa2a1d8e7bc
Maybe this helps in fixing the crashing issues when closing ProTools?
Thanks… Try what I’ve checked in now…
It’s ok, and avoiding the whole PluginInstanceInfo altogether is even much simpler.
I’m wondering… maybe it’s the case to do the same for the GUI class? Instead of composing JuceAAX_GUI with a ContentWrapperComponent that has the plug-in editor as its child, why not make JuceAAX_GUI itself a subclass of Component, moving in it the tasks that are currently done by ContentWrapperComponent?
No, it’s always best to avoid inheritance whenever possible, and I can’t see how that’d make things any better.
yeah, that makes sense indeed…
Still speaking about AAX, could you think of anything that causes the problem I’ve reported here? http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=10151#p60333
[quote=“yfede”]
Here is the patch as I’ve implemented it: https://github.com/yfede/JUCE/commit/8fc162ecc277fbefb331721d61633fa2a1d8e7bc
Maybe this helps in fixing the crashing issues when closing ProTools?[/quote]
Thank you for your help, your piece if code helped to stop constant crashes.
The latest juce tip already integrates these patches and also adds support for automation and MIDI.
I still get some crashes/hangs as reported in this post:
http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=10151#p60333
