Pulling from an AudioProcessorValueTreeState

Hey all,

I recently migrated to AudioProcessorValueTreeState and attachments to bind UI to parameter state and it’s working beautifully. I had a lot of parameters to track and it was much easier than adding listeners to UI components. I’m now in the process of trying to adopt the Synthesiser and SynthesiserVoice abstractions to eliminate some hand-rolled MIDI handling, voice-stealing, etc., reconciling that with AudioProcessor::processBlock. Looks good so far. I’m still having some awkwardness around updating state:

My synthesizer core is a simulator of some sound chips from another project of mine and they have their own internal state using small POD types, a uint8_t here, a uint16_t there, etc. Right now, updating its user-controlled parameters requires calling setters in that core type. It’s been a little awkward to get the data out of the parameter tree and push them into their appropriate setters.

Understandably, AudioProcessorValueTreeState seems to be designed to be the sole source of parameter state, where you “pull” from state directly as needed, but I’ve already got state in my synth core and it’d be pretty intense to convert all of those ivars to JUCE parameters. I’ve tried bringing up custom parameter listeners that have callbacks but it’s all very messy as you can imagine.

Are there any other methods that I haven’t tried that you’d recommend? I want to use the APIs in the idiomatic way and AudioProcessorValueTreeState was definitely the right call. Am I going to have to bite the bullet and have the synth core pull directly from the ranged parameters in the implementation?

Are you using the getRawParameterValue method in your Processor constructor? In the AudioProcessorValueTreeState tutorial, that method is demonstrated, to assign a set of Processor pointer members to APVTS parameters.

I’m not clear on your needs with interfacing your existing synth core with JUCE APVTS parameters, but from reading your post it sounds like maybe that’s one avenue you haven’t explored.