I’ve recently been thinking a little more about parameters and the new classes etc.
I currently have a derived parameter class of my own which basically takes a lambda in its constructor to be called when the virtual
setValue() function is called etc. The class has a few other little additions in there for NormalisableRange stuff etc. With the exception of the lambda it’s pretty darn similar implementation wise to the
I also use std::atomic internally for the value being set.
I saw this recent comment from Fabian:
I’ll look into this in more detail later today (need to wait until my FL studio download finishes ). Using AudioProcessorValueTreeState and SlideAttachments etc. is really the idiomatic way to do parameters nowadays and JUCE should really work when using these.
My question is would it be a worth while addition to use std::atomic in these parameter classes based on one of the compiler defines (COMPLILER_SUPPORT_C++11 or whatever) ?
I’m also wondering about the lambda/std::function approach rather than the use of listener/broadcasters.
For example to keep DSP units self contained am I right in thinking you would need to register the Processor as a listener for every parameter (using the AudioProcessorValueTree classes) ? Then in the listener callback you would need to have some kind of if / switch block checking against the ID of the param being changed etc ?
I’m wondering whether this is a little more boiler plate needed than a lambda (and potentially array of lambdas) added as a member function and whether a facility to add a std::function based callback would also be worthwhile in any of these classes alongside the listener/broadcaster based approaches ? (Again based on some compiler support macro)
Would be interested to know the JUCE teams thoughts on the future of the Parameter classes with modern C++ support etc.