Are legacy parameter methods going to be deprecated?


The legacy parameter methods in AudioProcessor which were marked deprecated over four years ago.

Are they actually going to be removed from the interface (please don’t), or can we treat that as an advisement to use the AudioProcessorParameter classes (please do)?

I know myself and others have completely different abstractions for handling parameters, and removal of those methods will either force us to maintain a fork or write wrapping code around the parameter classes’ interfaces.



We’re going to remove the methods at some point.

The required wrapping code is very simple:

Is there anything you cannot do if you use this wrapper? If you can present a compelling argument then that might stop us removing the methods.



On mac I got the deprecated warning if I call a deprecated method, but not if I override one. Anyone knows a working flag to get those?



note that those AudioProcessor methods were deprecated, but the comments were not changed and still read:
NOTE! This method **will eventually** be deprecated! instead of This method is deprecated!

btw, I noticed that AudioProcessor::setParameterNotifyingHost() is not deprecated. not sure if on purpose or not?



I don’t really understand what the wrapper classes help with? I’m trying to avoid AudioProcessorParameter and AudioParameterValueTreeState

Is there anything you cannot do if you use this wrapper? If you can present a compelling argument then that might stop us removing the methods.

It’s not so much what the abstraction can/can’t do so much as how they do it, and removing the “raw” parameter API will either force me to change designs or write a ton of boilerplate to fit a square peg into a round hole. That’s not to say I don’t use the classes ever, or think they don’t do their job, just that I would like the freedom to avoid them. I understand that “my code works now and won’t if you change stuff” isn’t the most compelling argument.

Here’s some arguments for keeping the API:

  • The Parameter/ValueTreeState classes are not zero cost abstractions and hide locking behavior (e.g. setValueNotifyingHost on a parameter with listeners which is called from operator=, which could be called from the audio thread, and I suspect plenty of people do).
  • The new-er API is not very cache-friendly (have to take care to deal with cache locality of parameters used together in the DSP)
  • Certain abstraction models, (like an Entity-Component System), are much simpler to deal with through the legacy API than the parameter classes.
  • With the exception of AUv3 (to my knowledge), all the plugin APIs have the same conceptual model for reporting parameters’ existence and changes to the host. If the primary goal of the AudioProcessor class is to serve as a least common denominator for those APIs, it does not make sense to abstract over an API that doesn’t need abstraction.
  • Not all of us are using AudioProcessor as the core of a product, rather as an API to target, or a prototyping system. The legacy API is easy to target or wrap, the Parameter classes are not.

I know maintaining an API is not free, and that there are probably features you intend to implement through the parameter abstraction (like you did with parameter groups, maybe sample accurate automation in the future?). But I don’t see any added value in removing the legacy API. To the contrary, it removes functionality that myself and others rely on.



You will not be able to avoid AudioProcessorParameter, though AudioParameterValueTreeState is completely optional.

The wrapper class shows how all of the deprecated AudioProcessor methods relate to calls via an AudioProcessorParameter. You can simply add those methods to your AudioProcessor subclass (or probably just remove override keyword) and have the wrapper call those methods on your subclass. There really isn’t much boilerplate required at all to keep your core functionality identical to how it was before - calls to the deprecated methods will simply be routed via the wrapper.