I have an application, which consists of an AudioClass and my GUI. The thing is: in my GUI there are several options, which affect the AudioClass.
I am wondering: what is the recommended way to communicate from the GUI to the AudioClass?
At the moment I have a global "ApplicationData" object, which I pass to most GUI components. From this global object it is possible to access the AudioClass.
E.g. I am doing something like the following from my GUI:
//inside of GUI:
MyComboBox::setAudio(String& waveFilePath)
{
applicationData.getAudioClass().setAudio(waveFilePath);
}
Is this a good way to model things? What do you recommend?
You can make the processor a memeber (http://www.juce.com/forum/topic/getprocessor-vs-member-pointer).
However communication, the forum here got some good posts regarding communication such as this (http://www.juce.com/forum/topic/whats-best-practice-gui-change-notification)
From my very short exprience as a noob in everything :) (DSP/C++) you should keep in-mind few things:
- You're multi-threaded. meaning you UI usually runs slower and is of course asynchornous to your processor.
- It usually wise to make the UI Thread (editor) read from the processor (with timer for example) and make sure all parameter changes or updates are actually managed asynchornously by the processor. (for example update a parameter but let the callback read it each time instead of updating it in the ui).
One thing I'm still struggeling hard to understand is concurrent handling where you have consumer/producer and wish to avoid locks (which are bad for the processor).
