getProcessor() vs member pointer

Audio Plugins
#1

Lately I’ve been trying to figure out the best way of giving objects access to other objects:
In the audio plugin demo, there exists a private method (it’s also inlined) that acts as an accessor to the AudioProcessor object:

JuceDemoPluginAudioProcessor* getProcessor() const { return static_cast <JuceDemoPluginAudioProcessor*> (getAudioProcessor()); }

This allows getAudioProcessor() to be called whenever a pointer to the AudioProcessor object is needed, right?
What is the advantage of using getAudioProcessor() over having a member variable (such as m_pAudioProcessor) that is set to AudioProcessor upon construction?

Also, as a side question, I’ve noticed that when creating a new audio plugin project via the Introjucer the PluginEditor.cpp is not editable via the GUI editor (in the Introjucer). I’ve ended up right clicking and selecting “Add New GUI Component”, and then using the addAndMakeVisible method in PluginEditor.cpp:

[code]CrossroadsAudioProcessorEditor::CrossroadsAudioProcessorEditor (CrossroadsAudioProcessor* ownerFilter)
: AudioProcessorEditor (ownerFilter)
{
// This is where our plugin’s editor size is set.
//setSize (800, 800);

MainComponent* m_pMainComponent = new MainComponent();
addAndMakeVisible(m_pMainComponent);
m_pMainComponent->setAudioProcessorParent(ownerFilter);
m_pMainComponent->setGainChange(&(ownerFilter->m_GainChange));

setSize(m_pMainComponent->getWidth(), m_pMainComponent->getHeight());

}
[/code]
(Also I know there is a much more elegant RAII method of doing this, but I haven’t quite gotten there yet)
Is there a way to be able to use the GUI editor on PluginEditor.cpp without having to add an extra header & source file?

Many many thanks in advance! :slight_smile:
Cheers,

Muir

#2

No - that editor class should be hand-written, I think that auto-generating it would be a bad idea. What you’re doing is correct, although there’s no need to allocate your component on the heap, you can just make it a normal member variable and avoid some boilerplate code.

#3

No - that editor class should be hand-written, I think that auto-generating it would be a bad idea. What you’re doing is correct, although there’s no need to allocate your component on the heap, you can just make it a normal member variable and avoid some boilerplate code.[/quote]

Thanks Jules! :slight_smile:

#4

Hey Jules, curious as to what the issue is with using a GUI component in a plugin? I know guys who write commercial plugs with the GUI editor and I just began work on my first utility plug and got the GUI editor up and running in my plugin session. You don’t suggest this?

#5

Not sure what your question has to do with this thread, but sure, there’s nothing wrong with using the GUI editor to build components, it’s just not particularly flexible, that’s all, and in most cases I’d be surprised if you can use it for even a reasonably complex GUI before you have to start hand-coding parts of it.

#6

I was doing something similar to the OP and was searching when I stumbled across his post, but your comment raised my curiosity is all. It has nothing to do with the original post really. Thanks for the answer.