I’ve got a situation where I need to be able to return arbitrary integers from an AudioParameterChoice parameter rather than simply the index of the selected choice. At the time of creating the parameter I have all the information available - the choices (list of strings) and values (list of ints). The choices obviously go in directly when creating a new AudioParameterChoice.
I see in the docs on AudioParameterChoice the example:
but it’s not clear how I would subsequently access the list of ints to replace the return value with the one from the list rather than the index. I probably also have to do an int to float conversion.
For reference, the context of this is trying to get FAUST to work better with Plugin GUI Magic, which means that a lot of the code is generated by the FAUST script and is often different than how you would write things by hand. I’m trying as hard as I can to fit into the existing ecosystem without imposing any constraints, etc. For example, FAUST ComboBoxes are really an extension of their Slider class and expect a float value, not an int.
It seems that you have to store the list of ints somewhere else. How about using another class to hold choices and values? Then you will be able to generate AudioParameterChoice and access the values from it. For example (I do not have a list of values here):
class overSample : public ChoiceParameters<overSample> {
public:
auto static constexpr ID = "over_sample";
auto static constexpr name = "Over Sampling";
inline auto static const choices = juce::StringArray{"OFF", "x2", "x4", "x8"};
int static constexpr defaultI = 0;
enum {
off, x2, x4, x8, overSampleNUM
};
};
I was hoping that I could attach that extra info to the Parameter somehow in order to make the process purely generic. When Faust builds a DSP function and UI, it basically stacks up the instructions to do so and runs them through a processing loop to build up the Juce ValueTreeState. At no point do I normally deal with any Juce code at all.
So I figure I have to:
a) grab the info that is not compatible with Juce during the loop which creates all of the AudioParameters. In the case of sliders, the mapping works pretty well so there’s no interpretation or loss of info, but for ComboBoxes there’s this extra stuff that really needs to be attached to the Parameter even if Juce natively does not know what that is.
b) Add a listener which will catch the UI events, and under the circumstances where such and such extra attributes exist, read them and use them to transform the Juce Choices to the discrete float values Faust DSP is expecting.
