# Is AudioProcessorParameter compatible to an AudioProcessorValueTreeState **URL:** \ **Category:** General JUCE discussion\ **Created:** [June 26, 2016, 3:48pm UTC](https://forum.juce.com/t/is-audioprocessorparameter-compatible-to-an-audioprocessorvaluetreestate/18222 "2016-06-26T15:48:08Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![ttg](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ttg/32/14456_2.png) [@ttg](https://forum.juce.com/u/ttg)\ **Post date:** [June 27, 2016, 5:13am UTC](https://forum.juce.com/t/is-audioprocessorparameter-compatible-to-an-audioprocessorvaluetreestate/18222/2 "2016-06-27T05:13:01Z")
You should’ve dig a little 😉 > [@Restrictions of AudioParameterFloat/Bool/Choice](https://forum.juce.com/t/restrictions-of-audioparameterfloat-bool-choice/16112): > > One of my favorite new features in JUCE 4 is the AudioParameter classes - however there seems to be a major shortcoming with them. Things like getting the raw normalized value and setting the unit label seem to be arbitrarily made private without any way to access them either during or after construction. It seems like it would make a lot more sense to make them either protected (so I can subclass and set the values myself) or make public methods to set these. As it stands now, it seems the only… If you wish to have simple management you should use AudioProcessorValueTreeState but then you’ll write a lot of lambda (also restrict your code to C++11 supported compilers if that’s something you care about). If you have few parameters you can enjoy the pre-configured AudioProcessorParameters you’ve suggested but you’ll need to write more management code. Currently they’re not working as a whole. --- _[View the full topic](https://forum.juce.com/t/is-audioprocessorparameter-compatible-to-an-audioprocessorvaluetreestate/18222)._