I need the values from my slider objects to compute the atmospheric absorption properties for 1/3 octave buffers, (essentially, the computations for absorption Coefficents etc become a gain value I can apply to each individual Buffer).
my question is: is it safe to call functions from prepareToPlay in an AudioPlugin?
The abosprtion Value and Coefficent calculation is done over 25 or so lines of code, split into around 5 functions, using the add, mulitply, /, and *, as well as exp() and pow(),
Is it possible/appropriate to call these functions from prepareToPlay, I also want the slider values to be usable by the user to change their settings, for example: it would not be appropriate to call this code from the constructor as then the user cannot change their settings and only the default slider values would be used in the computation.
I am wondering if I would need multi-threading, but that does not change the fact of where my abosrption gain computations need to be called from.
prepareToPlay is not a good place in the code to query parameters, it basically has the same problem you’d have if you got the parameter values in the constructor : the user might have no chance to set them up. It’s not completely determined how often and when the host will make the prepareToPlay calls. It might only be called once, before the GUI is even shown to the user.
The more common solution is to get the parameter values in the processBlock method and adjust the DSP as needed. If the calculations that need to happen are relatively expensive you’d want to track that the parameters actually changed and only then do the DSP adjustments. If the calculations are really expensive, then you’d probably want to offload doing the calculations in another thread.
In any case, you never should be dealing with the GUI sliders directly in the audio code, you need to use plugin parameters instead.
Yes you need audio parameters to be able to re-calculate your DSP once the sliders change. And you’ll want an attachment to sync your DSP and GUI, and then you’ll want AudioProcessorValueTreeState to glue everything together. The last one is not mandatory, but you WILL want it.
Thank you for your responses people, Currently they are juce::Slider objects,
and I have normal OOP style setters and getters using slider.getValue() to get the actual value I need. Why does this not suffice?
Your sliders may not even exist, because there is no guarantee that the editor exists at any given time. Plus, due to the fact the sliders interact on a different thread than the processing, you can have serious thread conflicts. Your processor should never access an editor (of which there could actually be more than one, theoretically). Your editor can access the processor (as long as it does so in a thread-safe manner, such as with atomics when writing to the processor from UI code), but not the other way around. You want your processing code to be lean and mean. Use parameters stored in an APVTS.
Thank you very much all, I have implemented an Audio Value Tree using the tutorial linked, I already had one for file loading purposes, but have added one now for my slider values, thank you very much for your help
You shouldn’t need more than one APVTS for your entire plugin.
But you are far from done. Very soon you’ll realize you want some sort of presets management system. Remember this: APVTS is not a preset manager, It’s a utility used by one. And you should get to know the getStateInformation and setStateInformation methods since these guys can do funny stuff to your GUI when you minimize and maximize your plugin during a session.
