i made my own parameter subclass and also my own wrapper class that holds pointers to all parameters in a big vector. with an enum class you can then index the parameters without having to use a string. but a method for creating a string from the enum class IDs is needed anyway because the parameter needs an ID and a name on creation. so it is totally imaginable to make a similiar system with apvts, where you’d first generate all parameters with apvts, then make a vector<atomic*> in your pluginProcessor and fill it with all the parameters as well, pretty much a one-liner when you prepared for this situation with that enum class stuff. then you also don’t need the string compares anymore but you’re still technically using apvts.
the real reasons for not using apvts come when there’re things that you just don’t like architecturally or when things are not possible with apvts. for example i disliked that apvts contained the state (valueTree) of the whole plugin, because that makes it seem like state is just parameter values. but state can be much more so i just felt like that was a bit odd and i outsourced state for that reason. also i wanted to be able to add features to my parameters and i wasn’t sure if i need the whole parameter system for that in the first place, so better safe than sorry i guess. added parameter features can be stuff like:
- the ability to lock a parameter from getting its value changed by either daw or gui.
- modulation systems that add value to the already existing value of the parameter on each block.
- stuff that prevents the plugin from crashing when a parameter is accessed by midi cc inputs while there’s already a gesture in place
- the concept of a unit. also with enum classes and string methods, can be helpful with all these valueToString-methods and stuff
etc.