Just a quick question…sorta.
How are folks handling the
parameterChanged() callback inside
I’m working on a project and decided I’d use the new parameter classes as until now I’ve just had my own subclass which takes in a lambda in the constructor that acts as a callback function whenever my derived parameter class’s
setValue() method is called.
I have some classes (processing units etc. that are members in my audio processor) that ideally I don’t want to be inheriting from
AudioProcessorValueTreeState::Listener as I’d like the classes to function outside of JUCE based projects.
So at the moment the way I can see things working is to add the processor itself as a listener which is registered to each of the value tree parameters one by one and then implement the
parameterChanged() method/callback in my audio processor.
This feels kinda messy though. It’ll mean a big old if else or switch type block to check the ID of the parameter changed and then call the relevant processing code.
My possible ideas were to have something like:
This would be a basic key value setup in which the key
is the parameterID and the
std::function is a callback/lambda function to be called when the parameter with the relevantID is changed. That avoids the big messy conditional block checking against String ID’s in the
parameterChanged() callback in my
The parameterChanged() callback can just find the callback with the parameterID key and call the std::function object in response to the change. No big if else checking block.
It all feels a little less than ideal though. I feel like I’m missing something in the way these classes are intended to be used. The various GUI attachments are really useful and save a lot of boiler plate so I would like to make this work if possible. At the moment it feels a little smelly…
Anyone have any advice ?
NOTE: This sort of relates to my other post: