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…
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?
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.
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
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?