GUI question - passing information between editors

Audio Plugins
1

Hi all,

I am fairly new to Juce, and I have come across something that is likely very simple, but nonetheless not clear to me.

In a simple (learning) project I have the following:

  • PluginEditor (no components are inserted)
  • Editor2 (some components are inserted)
  • Editor3 (some components are inserted)

Editor 3 is inserted into Editor2, and Editor 2 is inserted into PluginEditor.  Each of these inherit from AudioProcessorEditor, and are able to access the single instance of AudioProcessor.

Without using the AudioProcessor instance as an interface for the editors (which would seem a bit wrong), I am not sure how to make the editors talk to each other.  What I would like to do is update some of the components in Editor 2 when updates happen (typically through user interaction) to components in Editor 3.

I thought about making them friends, subclassing AudioProcessorEditor so I could include some mechanism for communicating in this fashion, and a few other things.  But, I keep thinking there is likely something I am just missing.

Do you know how I can make these editors talk to each other?

Thank you very much,

MKD

 

 

2

My first reaction is: try to adhere as much as possible to the MVC paradigm. The processor should be or own the model and the editors provide the controllers and views. So, try to communicate by changing data in the model/processor, which can then notify editors to update their controls and visuals. Juce has several tools for this: Values, Listeners etc.

I am often refactoring my plugin's code to be more and more strict with this.

And mind you: there is only an editor when the user has opened one in the host. Most of the time there is no editor. So make sure your plugin works correctly with all its settings and processing without an editor.

3

You should only have one subclass of AudioProcessorEditor. The processor will only return one type of object for its UI, and it makes no sense to use that as a base class for anything else. (It may even cause problems or assertions, as the classes won't expect you to use it in that way)

4

Well, that does make sense.  Thank you both.