Best practice? Parameter changes from and to the ui

Audio Plugins
1

Hello all!

It’s been a while since I;ve posted here, but I surely will come back much more in the future.

Building a plugin (Introjucer FTW!) and I was wonderting what best practices people use for sending parameter changes to and from the UI. I’m talking both automation and regular parameter settings via the host (for example when loading presets).

I’ve seen the GenericAudioProcessorEditor uses the AudioProcessorListener for this plus a timer which checks the values once in a while and updates them if they are dirty. In the example of GenericAudioProcessorEditor this is quite easy because all parameter UI objects are identical, but for other cases it becomes (much) harder. Having one big timer which updates absolutely all parameters once in a while seems total overkill to me, especially for large UI’s.

So, what should I be using or looking into?

thx,

  • bram
2

Well I’m currently experimenting using juce::Value’s to hold my parameters making my AudioProcessor subclass Value::Listener so I can respond to a single value change (checking the value using refersToSameSourceAs()). You can then easily attach UI objects e.g. Slider::getValueObject().referTo() and do a similar thing in custom UI components. Seems to all work smoothly at the moment, will report problems if I find them.

3

That sounds nice and clean Dave but whats the performance like? If you had a lot of parameters, that must incur a lot of overhead no?

How are you dealing with the threading issue as well?

4

I'm interested in this too. I'm buliding an app thats analyzing audio input and would like to trigger various UI changes according to the incoming data. I like the idea of seperating UI elements from the data processing and looking into using Value and its listeners to do this. I'm concerned about performance hit if it might be significant... 

5

See this thread:

http://www.juce.com/forum/topic/whats-best-practice-gui-change-notification

 

 

6

Thanks bazrush !