Interfacing with AudioProcessorParameters as a host

Audio Plugins
#1

Hi guys, I’m attempting to implement plugin parameter automation support in my host. The old api has been deprecated and there’s a lot of threads about AudioProcessorParameters but mostly from a plugin dev’s perspective, so it’s been a bit tough to piece some of it together from the hosting side of things. I have the following questions:

1.) I’m gathering that as a host I should be making use of parameter ID’s instead of indices. Fabian created a thread announcing support for reporting ID’s to the host here: https://forum.juce.com/t/breaking-change-audio-parameter-id-support/17594

Assuming I should in fact be using ID’s:

  • How do I access a parameter’s ID? I do see internal usages of AudioProcessorParameterWithID class, but that’s not exposed other than via LegacyAudioParameter::getParamID.
  • AudioProcessorParameter::Listener api provides a parameterIndex. Is this indeed the index and not the ID? If so, how do I go about matching up with the ID? Am I approaching this wrong?

2.) I’ve noticed that GenericAudioProcessorEditor impl holds onto a reference to the AudioProcessorParameter. What lifetime guarantees do we have for parameters? I’ve read that parameters can be dynamic in some cases which makes me wonder about this.

Any tips are appreciated. Thanks!

Wrapping plugins and deprecated parameter methods
#2

At the moment, as a host, you cannot access parameter IDs. This is certainly the way to go in the future, but we’re not quite there yet - we’re gradually phasing out the “old” way of managing parameters (on both the plug-in and the hosting side) which we need to keep supporting for a while yet.

JUCE also doesn’t support dynamic numbers of parameters. I’m not sure how JUCE-based hosts manage this.

#3

Hi Tom, has there been any progress in this area? If not, can you share where this falls on the priority list?

1 Like