In Tutorial: Create a basic Audio/MIDI plugin Part 2: Coding your plug-in I read that
When passing information between these two [Processor and Editor] it is best to consider the processor as the parent of the editor. There is only one plug-in processor whereas you can create multiple editors. I have however not been able to figure out how one processor can have multiple editors.
What I have thus far tried is to split up a “Main” Editor into several logical parts (see attached photo). For each of the three sections Header, Body and Footer the idea is to create separate classes that inherent from the
AudioProcessorEditor and all talk to a PluginProcessor instance. Does this way of thinking make any sense? If so, I realize that the
AudioProcessor has the createEditor (a editor, singular) function. How can I divide the Editor into subparts? What is the logical way to achieve what I am trying to do?
The Editor is a JUCE Component. Components can have sub-components (which are also JUCE Components), that you layout in their parent component. You don’t need to have multiple AudioProcessorEditor classes, just add subcomponents. You’ll find examples in the “examples/PlugInSamples” directory.
EDIT: actually there is no good example of the Editor in “examples/PlugInSamples”, maybe this could be improved?
Yes, I had already looked around for examples of how to implement that kind of structure but found no valuable examples. So if I implement, say the header, as inheriting from the Component class, how would I make a component inside it, i.e. a Slider, talk to the Processor instance? Normally this seems to be done as something like
processor.value = slider.getValue(); inside a
sliderValueChange function. In this case however the class that owns the slider, namely the header class, does not have direct access to the processor.
I feel like I am missing a key point…
You store a reference to the processor in a member variable of the editor head class. Sort of
class EditorHeader : public Component
processor = proc;
And in the Editor constructor you do something like
header = new EditorHeader(processor);
header->setBounds(0, 0, someWidth, someHeight);
By following this kind of code I got the dreaded segmentation fault, which was issued when I ran
body->setBounds(...) in the parent
resized method. Instead what I did is I implemented a setter method in the child class, like
body.setAudioProcessor(&processor); that I call in the decorator of the parent. That appears to do the trick, but I am open to other ideas.