AudioProcessorValueTreeState Improvements

Alright, thanks, that makes more sense! So the basic pattern is: create your unique_ptr, store the derivative ptr in your processor, pass the unique_ptr to the tree.

1 Like

The recommended way is now to construct the AudioProcessorValueTreeState directly with a ParameterLayout containing all the parameters.

I got some code where I pass around the valueTreeState to different classes at construction, and create a couple of parameters within my mainProcessor, and some other ones in those other classes. something along those lines :

struct MainProcessor : public AudioProcessor
{
    MainProcessor()
    : state (*this, nullptr)
    , anotherProcessorClass (state)
    {
        state.createAndAddParameter (...);
    }

    AudioProcessorValueTreeState state;
    AnotherProcessorClass anotherProcessorClass;
};

struct AnotherProcessorClass
{
    AnotherProcessorClass (AudioProcessorValueTreeState& state)
    {
        state.addListener (this);
        state.createAndAddParameter (...);
    }
};

Was it bad practice?
It seems to me I can’t really do that anymore with the new recommended AudioProcessorValueTreeState constructor no? (I only had a quick look, so perhaps I’m missing something simple)

Is there a straightforward way of attaching Projucer-generated GUI elements (e.g. Sliders, Buttons etc) to AudioProcessorValueTreeState?

===
I am using Projucer [v5.4.1] to add a Slider as a GUI subcomponent.
I would like to be able to use SliderAttachment to attach that Projucer-made Slider to a parameter within the APVTS, but with Projucer, I end up with following code:

in AudioPluginEditor.h

private:
//[UserVariables] – You can add your own custom variables in this section.

AudioProcessorValueTreeState &valueTreeState;
typedef AudioProcessorValueTreeState::SliderAttachment SliderAttachment;
std::unique_ptr<SliderAttachment> testAttachment;

//[/UserVariables]

//==================================================== 
std::unique_ptr<Slider> test_slider;

in AudioPluginEditor.ccp

// constructor...
testAttachment.reset(new SliderAttachment(valueTreeState, "test_int", *test_slider.get()));

// destructor ...
///[/Destructor_pre]
test_slider = nullptr;
//[Destructor]. You can add your own custom destruction code here...

The problem is that “test_slider = nullptr” throws an exception:

“Exception thrown: read access violation.”

… , but, when I add my own - not Projucer-generated - code for a Slider& as a class member:

Slider &member_slider;

and

testAttachment.reset(new SliderAttachment(valueTreeState, "test_int", member_slider));

… it works fine.

The above suggests some rather inelegant, makeshift workarounds involving copy&paste, but I am wondering if there exists a more systemic approach.

If you have a set number of elements I would just make them members, in the case of that generated code they’re destroying test_slider before the slider attachment which isn’t allowed (you’ll have to add testAttachment = nullptr before the line where test_slider is set to nullptr)

If your slider is a member and the slider attachment is heap allocated to a std::unique_ptr then the destruction order will be fine

Thanks.
The point is that I am already spoiled by Projucer’s interactive GUI layout features and don’t want to regress to adding GUI class members by hand.
In the “days of yore”, Projucer used to make “plain” members.
Perhaps it would be a good enhancement to add an option to Projucer that would allow a choice between heap and stack allocation. Just an idea that may turn out to be naive in the context of other forces at play.

AFAIK the GUI editor is basically there for legacy reasons, in this post it’s mentioned they don’t plan to add any features to it.

1 Like

I’m looking at one of my first plugins to bring it up to date with what I’ve learned in the last year and to use 5.4.1 but I can’t seem to get an AudioParameterChoice to initialise using the example given.
This is the sort of thing I’m doing :

auto choice = std::make_unique<AudioParameterChoice> ("choice", "Choice", {"Choice 1", "Choice 2", "Choice 3", "Choice 4"}, 1);

but the compiler complains No matching function for call to 'make_unique'

However my original code doing something like :

auto choice = new AudioParameterChoice ("choice", "Choice", {"Choice 1", "Choice 2", "Choice 3", "Choice 4"}, 1);

or even doing :

std::unique_ptr<AudioParameterChoice> choice;
choice.reset( new AudioParameterChoice ("choice", "Choice", {"Choice 1", "Choice 2", "Choice 3", "Choice 4"}, 1) );

doesn’t complain at all.

What am I missing?

The previous version called the Constructor, so it had the proper type information available to implicitly cast the Strings initialiser list to a StringArray. The make_unique however doesn’t have the argument types of the constructor available, it just forwards the arguments.

The solution is, to supply the type like:

auto choice = std::make_unique<AudioParameterChoice> ("choice", 
                                                      "Choice", 
                                                      StringArray ({"Choice 1", "Choice 2", "Choice 3", "Choice 4"}), 
                                                      1);

Haven’t tested it, but something like that should work…

3 Likes

Thanks, exactly that! I even looked at that and thought, "no must be fine if it works with new". Useful to know that restriction about make_unique.

Could your AnotherProcessorClass have a method that returns an array of AudioProcessorParameters (or perhaps a group of them) which you could then pass to the ParameterLayout constructor after you’ve initialised?

Something roughly along the lines of:

struct MainProcessor : public AudioProcessor
{
    MainProcessor()
        : state (*this, nullptr, "state", anotherProcessorClass1.getParameters(), 
                                          anotherProcessorClass2.getParameters()), 
    {
    }

    AudioProcessorValueTreeState state;
    AnotherProcessorClass anotherProcessorClass;
};

not really, because my “AnotherProcessorClass” constructor is expecting the AudioProcessorValueTreeState as parameter.

Of course I could change that, do things differently, but I wanted to stress the point that the new way can imply quite a few changes.

I just hope you will keep the old constructor around for a while… (I’m really not against the latest changes, which are most likely an improvement, but it’s quite some work to stay up to date with changes and depreciations lately)

Hi All,
I am playing around tutorial Cascading plug-in effects using processors which already use APVTS, similar like @lalala mentioned.

For now I had implementation more or less like @t0m proposed, but I wondering if each processor could have its own APVTS. Then in main processor methods getStateInformation and setStateInformation would be a little more complicated. But I think AudioPluginHost has such implementation already. There is static function createNodeXml in FilterGraph which calls
node->getProcessor()->getStateInformation (m);

Is there anything against using own APVTS object in all “anotherProcessorClass-es”?
Does it sounds reasonable?

Kindly regards,
Mateusz

I think it’s good that you’ve got the AudioParameterX classes back into the APVTS stuff. However, the best practice method seems to make it hard (impossible?) to use NormalisableRange::setSkewForCentre().

To grab an existing chunk of code as an example:

auto bwp_range = NormalisableRange<float>(MINUS_THIRTY_SIX_DB, 1.0f); bwp_range.setSkewForCentre(Decibels::decibelsToGain(-8.0f)); brick_wall_param = parameters.createAndAddParameter(std::make_unique<Parameter>("limit", "Target Max Signal", "dB", bwp_range, 1.0f, db_to_text, db_from_text));

Using parameters.getParameterRange("limit").setSkewForCentre(Decibels::decibelsToGain(-8.0f)); after the constructor block doesn’t work because getParameterRange returns a copy of the NormalisableRange.

parameters.getParameter("limit")->getNormalisableRange().setSkewForCentre(Decibels::decibelsToGain(-8.0f)); doesn’t work because this time it returns a const.

Any recommendations?

I haven’t tried it, but I would expect something like this to work:

juce::AudioProcessorValueTreeState::ParameterLayout makeParameters() {
  auto param = std::make_unique<juce::AudioParameterFloat>(...);
  param->range.setSkewForCentre(...);
  return { std::move(param), /* any extra parameters go here */ };
}

// When constructing your apvts
MyAudioProcessor()
  : apvts { *this, nullptr, "state", makeParameters() }
{
}
1 Like

Thanks, that seems so obvious now. :thinking:

thanks @t0m this post was super helpful for migrating to the new AudioProcessorValueTreeState management!
one question: let’s say I want to create an AudioParameterFloat in the createParameterLayout() method like above…I can use the other AudioParameterFloat constructor to insert almost all the old attributes…but isMeta and isAutomatable still seem to be missing (isChoice too but I assume that’s covered by the choice param…)
…is there a way to set those two in the new code??
thanks!

1 Like

I’m on board with this change, but I have a couple of questions:

  1. The suggested way to migrate legacy code is to replace:
createAndAddParameter (paramID1, paramName1, ...);

with

using Parameter = AudioProcessorValueTreeState::Parameter;
createAndAddParameter (std::make_unique&lt;Parameter&gt; (paramID1, paramName1, ...));

That works fine, but it still relies on the old constructor, I think?

apvts (*this, nullptr)

And since this constructor is deprecated, isn’t this new method of adding parameters just as fragile as the old method? i.e. it will stop working in future, due to the old constructor being removed.

  1. In the past parameters were created in my processor’s constructor, which gave me the freedom to interact with class members as I was adding each parameter. For example I might keep an array of bools that indicated whether changes in value to a particular parameter should be smoothed:
MyProcessor::MyProcessor()
    : state (*this, nullptr)
{
    state.createAndAddParameter ( ... )
    paramsShouldSmooth.add(false); // update a class member with info about this param

    state.createAndAddParameter ( ... )
    paramsShouldSmooth.add(true); // update a class member with info about this param
}

Presumably it is no longer possible to interact with my processor’s class members in “real-time” while I am adding parameters, and any such interaction would have to happen after all the members have been created?

1 Like
  1. You can use the new Parameter type with the new constructor and ParameterLayout, but you will have to migrate away from createAndAddParameter eventually.
  2. The new interface does mean we have to do things slightly differently, but the advantage of this approach is that we can avoid two-phase initialisation. A lot of beginners seem to get caught out by forgetting to initialise the state member… If you really really need to tweak data members while setting up parameters, you can add a function with the following signature to your class as a private member:
static ParameterLayout setUpParameters (MyProcessor&);

Then, in your initialiser list you would

: apvts { *this, nullptr, "tree", setUpParameters (*this) }

I stress that this should be a last-resort technique though.

Also, due to the order of data member initialisation in C++, you should ensure that the apvts member is declared after any members you modify in setUpParameters in the processor class definition.

3 Likes

Thanks reuk. For future plugins I will follow the recommended approach, but I think your suggestions will help me to refactor one of my old plugins. I hadn’t considered passing a reference to processor to ParameterLayout.

Jan 12

thanks @t0m this post was super helpful for migrating to the new AudioProcessorValueTreeState management!
one question: let’s say I want to create an AudioParameterFloat in the createParameterLayout() method like above…I can use the other AudioParameterFloat constructor to insert almost all the old attributes…but isMeta and isAutomatable still seem to be missing ( isChoice too but I assume that’s covered by the choice param…)
…is there a way to set those two in the new code??
thanks!

This is an important part of dynamic parameters? Any news. Would be great to have an alternate dummy system, where isAutomatable and other attributes can be edited later. The number of required dummy parameters and their ids alone could be set on init.