I’m now refining the SamplerPluginDemo and adding ADSRs for amplitude and filters etc. The original project has an interesting “data model” pattern that I’d like to understand better.
Since I’m adding ADSRs, I extended the data model with a new class MPESamplerVoiceDataModel for the MPESamplerVoice. My UI is a mess, but the ADSR sliders work as desired with this new data model.
However, now I want to call
getParameters() on the SamplerAudioProcessor class. I’m seeing that it has no parameters because the SamplerAudioProcessor’s constructor doesn’t create a layout and AudioProcessorValueTreeState like AudioProcessorValueTreeState and TheAudioProgrammer/helloSampler.
How can I reconcile the “data model” philosophy of the demo with what seems like the more common way of creating
AudioParameterFloat? I think I would be violating the philosophy if my
MPESamplerVoiceDataModel had an
AudioProcessorValueTreeState, which would in turn be constructed with a reference to an audio processor. I’m pretty sure that a data model shouldn’t have a reference to a processor, which would violate model-view-controller.