I programmed in AudioPluginFramework a class MyVoice : public SynthesiserVoice. The parameters like gain etc. are public floats in class MyFilter:public AudioFilterBase,public ChangeBroadcaster. Now I am programming inside the MyVoice-renderNextBlock-function. How can I get access from here to the parameters in MyFilter?
Thanks for your help
What I would recommend doing is not storing the actual parameter values in the Filter at all. One way is to use the SynthesiserSound class as a holder for Configuation objects. A Configuation object contains the parameter values for different dsp blocks. Each dsp block is given a configuration object when it is setup and SetParameter then updates the values in the Configuration. This is the best way to go if you envisage alot of parameters in the final version.
Thank’s a lot for the good comments. Now I see things a little clearer.
I think I will try it the following way:
building a new class VSTParameters with an array for the Params and including the VSTParams-transformation-staff like normalizing Params to 0…1 and so on
the constructor of the Sound will build the VSTParams-class because it looks pretty consequent to combine a sound not only with it’s key range but also with it’s specific Params
inside the Voices I need a memory-block to hold the values calculated from the Params, the velocity, the frequency ….
Inside the AudioFilter I will store pointers on the Sounds and the Voices
AudioFilter::setParameter calls then currentsound->setParameter (which updates the Param in the Sounds own Param-memory) and there is also a call to all the Voices needed which are currently playing the currentsound to update the calculated values used in the rendering function of the Voice
I hope this will perform well . For a c++ newbie like me it’s hard to know.
i use an unobtrusive way to do this, i just don’t care where my real parameter are defined or used inside my dsp building blocks:
every dsp have its internal stuff with its getters and setters methods, and i’m linking them to the “outside” realm via delegates (or functors if you like best).
this way you can still build you filter the way you feel comfortable with, build it as a standalone class without any other class pointer involved but still let parameters be easily accessible from the wrapper, gui and host point of view (and all with the necessary mappings, descriptions etc… ).