| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
juce_gui_basics [2021/02/08 21:08]
shane [JUCE is NOT (fully) a Model-View-Controller based framework] |
juce_gui_basics [2021/02/08 23:52]
shane [Subclassing JUCE GUI classes] |
| You might choose to subclass //juce::Button// if you want to create your own type of button widget with unique appearance and behavior. To respond to the button being clicked, you would overload the //clicked()// member function. To change its appearance, you would overload //paint()//, and so on. | You might choose to subclass //juce::Button// if you want to create your own type of button widget with unique appearance and behavior. To respond to the button being clicked, you would overload the //clicked()// member function. To change its appearance, you would overload //paint()//, and so on. |
| |
| Creating a derived class like this allows you to override as much of the standard class's functionality as you like, and inherit the rest. | Creating a derived class like this allows you to override as much of the standard class's functionality as you like, and inherit the rest. It's usually more work than the other two approaches. |
| |
| ==== Listeners ==== | ==== Listeners ==== |
| As you see from the above sections, GUIs for audio plug-ins are not built according to anything like an MVC pattern. You will, however, find a few spots where MVC-like ideas are applied, the main one being the [[https://docs.juce.com/master/classListBox.html|ListBox]]/[[https://docs.juce.com/master/classListBoxModel.html|ListBoxModel]] pair of classes: to create a scrolling list, you use a //juce::ListBox// component, which is completely generic, and link it to a //juce::ListBoxModel//-derived object which contains the specific data to be listed. | As you see from the above sections, GUIs for audio plug-ins are not built according to anything like an MVC pattern. You will, however, find a few spots where MVC-like ideas are applied, the main one being the [[https://docs.juce.com/master/classListBox.html|ListBox]]/[[https://docs.juce.com/master/classListBoxModel.html|ListBoxModel]] pair of classes: to create a scrolling list, you use a //juce::ListBox// component, which is completely generic, and link it to a //juce::ListBoxModel//-derived object which contains the specific data to be listed. |
| |
| ==== Headline ==== | ==== Plugin Processor and Editor ==== |
| | JUCE implements a plug-in using a pair of classes: |
| | * The DSP code is called the plug-in //processor// and is derived from [[https://docs.juce.com/master/classAudioProcessor.html|juce::AudioProcessor]] |
| | * The GUI is called the //editor// and is derived from [[https://docs.juce.com/master/classAudioProcessorEditor.html|juce::AudioProcessorEditor]] |
| | |
| | The //processor// is what is instantiated by a host (e.g. DAW). It has a //createEditor()// method, whose job is to create an instance of the //editor// and return a pointer to it. The editor has a member variable which is a reference to the corresponding processor instance; through this reference, the editor can communicate with the processor, call its methods, get at public member variables, etc. (This is a //convention//, not something which is enforced by the class definitions.) |
| | |
| | Because the processor can exist alone, i.e., there is no requirement that the host //ever// instantiate the editor, and most hosts actually delete the editor instance each time the user closes the plug-in GUI window, there is no reciprocal arrangement where the processor can get at "the" editor. (There are ways, but they are indirect.) The more common pattern is that the editor (or any of its child components) are set up as //Listeners// of the processor, so they get callbacks when its state changes in a way that requires the GUI to update. The JUCE classes [[https://docs.juce.com/master/classChangeBroadcaster.html|ChangeBroadcaster]] and [[https://docs.juce.com/master/classChangeListener.html|ChangeListener]] are most often used for this. |
| | |
| | As mentioned above, JUCE's "attachments" mechanism allows GUI controls to be connected directly to the corresponding plug-in parameters (which themselves are embedded in a //juce::AudioProcessorValueTreeState// member variable of the processor). These connections are two-way and work basically automatically. |
| |
