Breaking Change: Hosted AudioProcessorParameter improvements

[frankfilipanits]

@t0m

The motivation for this change is reduce the size of the AudioProcessor class. […] This is the first step towards this goal; the next is to deprecate the same AudioProcessor methods when implementing plug-ins too.

Just stop.

This is the FOURTH JUCE attempt in about as many years at getting plug-in parameters right and at this point I have ZERO confidence in it doing anything except breaking a lot of code and creating headaches for people who have legacy plug-ins to support. As lalala said:

@lalala

Also keep in mind what we’ve been through :

Custom parameters classes.
Then AudioProcessorParameter.
Then AudioProcessorParameterWithID.
Then AudioProcessorValueTreeState.

Now after a year or two that the recommended way is AudioProcessorValueTreeState, it still does not work properly. I know you do your best, but understand that this is a bit annoying, and that people are still reluctant to drop their custom classes until they see a lasting stable solution. When such a solution is here, then only you can consider to mark those methods as deprecated imo.

Don’t give us another 90% “solution” and forcibly break things for those who have rolled their own custom classes that work 100%.