I have been creating plug-ins following the example in the tutorial titled “Tutorial: The AudioProcessorValueTreeState class” and I find this the easiest way to get a plug-in up and running. So now I have a feature request: provide an option in the new audio plug-in menu to somehow specify that I want to go this route. Make this create PI processor and editor files that include at least some of the additions and changes that I now make manually. For example, have “parameters” already defined. This way, I don’t have to refer back to the tutorial or previously created plug-ins to make all the little changes that apply to this approach. No big hurry!
Yes, as we will soon deprecate the old parameter system anyway, I think the new default audio plug-in template will be a plug-in which uses the AudioProcessorValueTreeState class.
Sounds good! I could not get the old system to work, at least not with Audacity.
I don’t really agree with that, unless there are other options provided as well: one thing is to provide tools for a plug-in to be made, another is to enforce a specific policy or data structure.
The AudioProcessorValueTreeState may have several advantages, but certainly it is not a good fit for every conceivable plug-in out there, so I think it is a better idea not to give the impression that one is forced to use it.
If you wish to include a template that uses it, please at least provide an alternative template which doesn’t (and that simply instantiates parameters without connecting them with a tree)
1 Like
Please never ever make AudioProcessorValueTree mandatory! Its currently not even working flawlessly, also its very monolithic, and duplicates existing functionality.
1 Like
agreed, undo/redo seems to be fragile, haven’t used it myself. I read about concerns about thread safety, I don’t know how bad that is, I didn’t experience problems in that respect so far.
which enables a simple one line set and getStateInformation. That wouldn’t be possible without a central data structure, and a tree has many advantages, especially with the possibility to add all private information underneath, that is not exposed to the host, but still saved in the host’s projects.
probably, because people like to keep old approaches… sorry, that contradicts itself.
I doubt somebody will pull the plug of all existing code. And having a more OO approach than the original simple callbacks in AudioProcessor class, I don’t think anybody wants to go back there…
Just my 2 pennies
probably, because people like to keep old approaches
no, AudioParameterFloat was introduced at the same time, and until now the AudioProcessorParameterValueTree isn’t even usable (at least for me)
And having a more OO approach than the original simple callbacks in AudioProcessor class
you mixing different things, my criticism isn’t about that
AudioProcessorParameterValueTree does too much things … value/range logic, should be completely separated from the save/restore logic
for parameters we already have AudioProcessorParameterWithID
a separate class, which only handles the save/restore logic would be enough
The AudioProcessorValueTreeState::Parameter inherits AudioProcessorParameterWithID, so they are not too far apart. Maybe there is a middle ground, but like you say, currently these two paradigms duplicate functionality, and they will drain development resources from each other.
I don’t know, if the plans are to axe the AudioParameterFloat/Int/etc. completely…