AudioProcessorParameters of a hosted plug-in with all the information available when you are implementing an
AudioProcessorParameter. This means that it is much easier for hosts to present a more comprehensive interface to a plug-in’s parameters. We’ve used this extra information to improve the
GenericAudioProcessorEditor class, as shown in JUCE’s Demo Host below:
For an example of how to use hosted
AudioProcessorParameters you should have a look at the source code in
This commit also deprecates all the
AudioProcessor class methods which take a parameter index as an argument (such as
const String AudioProcessor::getParameterName (int parameterIndex)) when hosting plug-ins. No changes are required if you are implenting a plug-ins. Unfortunately it is impossible to deprecate these methods and issue only a compile-time warning, so a single assertion is fired the first time you use one of the deprecated methods. To continue to use the deprecated methods you’ll need to push past this assertion in your debug builds, or temporarily disable in by modifying JUCE’s source code.
The motivation for this change is reduce the size of the
AudioProcessor class. Not only will this improve the interface, it will also make ongoing development much easier; as it currently stands any changes relating to parameters needs to be duplicated in the
AudioProcesssorParameter classes. Even now some functionality is only available through the parameter classes and the gap between the two ways of doing things is only going to widen when we add things like parameter groups. This is the first step towards this goal; the next is to deprecate the same
AudioProcessor methods when implementing plug-ins too.
Summary: When hosting plug-ins you should use the
AudioProcessor::getParameters() method and interact with parameters via the returned array of
AudioProcessorParameters. If you don’t you’ll need to push past an assertion in debug builds.