The latest tip of the develop branch has deprecated the AudioProcessorValueTreeState::createParameter method in favour of creating parameters in the APVTS constructor:
However, this isn’t at all sufficient for plug-ins with many, duplicated parameters.
In my case, I have a plug-in with N filters (where N is a constant defined in a header file) and each filter has parameters for corner, gain, q, etc. and so I use a simple for loop to create the parameters using APVTS::createParameter.
What would be the recommended way of doing this now, I don’t fancy having a mess of copy-pasted code to setup all my parameters!
I am writing a dynamic plugin that loads from an XML document. The different process blocks are connected using AudioProcessorGraph. Each process block requires different parameters depending on what it is. It will be fully user editable. I have to load a couple of hundred unnamed parameters and add/remove names to show/hide. It appears as though a number of other JUCE users are doing similar projects, especially synths. Over the years of threads, there was always a hint of JUCE supporting dynamic parameters. Being able to load parameters based on an initial presets would have been great. This latest change appears to be a definitive move away creating parameters from a preset.
I am not the best programmer, but I am learning.
It appears that some limited parameter creation can still happen in setStateInformation. I am still looking through the JUCE code to see when setStateInformation occurs, but I assume the DAW gets the initial preset before setting up final DAW automation, etc. APVTS and the new groups are limited to initialisation, before loading this initial preset.
I love what JUCE are doing, but I am wondering if they are painting the code into an unnecessary corner.
They were previously limited to the constructor, so almost nothing has changed there. Whilst these APVTS improvements are related to parameter management, supporting a dynamic number of parameters is a separate issue.
Thank you so much for your time. You are very talented and I mean no disrespect.
I am aware of this. I have added groups. They are fantastic. I love the idea fo specialisation of parameter types, this will replace a lot of my coding.
Does the consolidation of the methods, to a single initialisation, indicate that they will not ever be able to be used in setStateInformation, though the plugin architecture may have technically allowed some form of APVTS to be used in setStateInformation. I still have to look further into the order of method calls for parameter creation and setStateInformation.
Can any of my large number of the parameters be edited in the initial setStateInformation? For example can the parameter Lamdas be added on a per needs basis in the initial setStateInformation?
Not the answer for what you asked, but kind of:
You can’t rely on that there is a setStateInformation at all. A host does not know anything about your plugin’s save format at all. There has to be at least one getStateInformation call before (could have happened in a previous session, that is now being restored).
Many hosts send only one time a setStateInformation, when a session is restored, but not at all for a new session.
If you use your own RangedAudioParameter subclass then you can do whatever modifications you wish. The difficulty is propagating this information via the plug-in SDKs to the host. For example, parameter name changes have only just become possible via the VST3 SDK (and are not yet supported by JUCE):
With dynamic parameter ranges you may have differing levels of success in different hosts and formats.