AudioProcessorParameter class from Juce Host side


#1

Hi

I’m a bit confused about the AudioProcessorParameter class from a host perspective. (I’m coding a plugin host not a plugin)

So I want to get the number of parameters a plugin has and display their names.

I could loop getParameterName for getNumParameters(), But then I read that these functions are depreciated in favor of the AudioProcessorParameter. Great, seems like a good idea.

But VSTPluginInstance does not seem to return a filled array with the parameters when calling getParameters(), but if you call the old getNumParameters() it boils down to this code in juce:VSTPluginFormat:

int getNumParameters() override      { return effect != nullptr ? effect->numParams : 0; }

What am I missing here, how should the host access the parameter info?


#2

Calling getParameters() is the correct way to access them. Maybe you just need to initialise the plugin first, so that it has a chance to populate that array?


#3

Thank you for getting back to me.

Well the plugin is initialized, as far as I know, playing audio etc.

I then call getParameters() in a button call much later.

Is there a special function I need to call on the plugin? 

I have searched around in the code, and cannot seem to understand where this list is populated. It seems to me the AudioProcessor class is the only one that accesses the managedParameters array directly, and when searching I can’t find any calls to AudioProcessor::addParameter (AudioProcessorParameter* p) from other classes (Except in Juce_aax_wrapper and juce_vst3_wrapper)

Sorry if I’m way of track here…


#4

It appeared the same way to me. Neither AU nor VST plugins would populate the getParameters() list for hosts. Back then i thought that the transition just hasn't been completed but that is quite a while ago by now ...


#5

Thank you for confirming luzifer, I have decided to let this issue be for the moment and use the old functions (that Jules told me not to use) and wait for the new system to get up and running.


#6

Just checked this and oops, yes, we've not yet implemented the new parameter APIs for those wrapper classes! It's on our backlog, but in the meantime you can still use the old methods to interact with parameter values.