How to create my own parameter class?

Audio Plugins
1

Hey everybody,
I just started learning Juce and C++ in order to develop a drum sampler VST, like Addictive Drums and so on.

Now, i know that is a very hard goal to reach, but i really wanna learn how to do this stuff (I mean VST programming in general) and, one little problem at a time, I’m getting better at it.
At the moment I’m stuck with parameters management, I’ve seen a lot of topics talking about this, and at first time I was going to implement the AudioValueTreeState like tutorials and many others said, and it worked, also it was quiet simple for a beginner like me.

Then I discovered that the ValueTree has some problems and it’s better for now not to use it.
So someone suggested me to make a separate file with my own class for managing parameters, and told me that I had to inherit from AudioProcessorParameterWithID.

And here I got stuck. I just can’t figure out how to do this without falling in compile errors or memory leaks, tutorials/forums use many different type of solutions to the problem, but their environment is always different from mine. Someone uses the ValueTree, others use AudioParameter objects and so on, I tried to merge all the hints and infos I could, but I get an unhandled exception from Visual Studio when I call the addParameter() in my processor.

Is there someone who can tell me the proper way to do this please?

I’m using 2 separate files called PluginParameters(.h / .cpp) and of course the 4 default PluginProcessor and PluginEditor files.
In my processor I’m using a pointer to my custom class like this:

class DrumSamplerAudioProcessor  : public AudioProcessor
{
public:
    ...
    PluginParameters* parameters;
    ...
};

Then in PluginProcessor’s constructor:

addParameter(parameters->pKickLevelParam);

The PluginParameters class looks like this:

PluginParameter.h

#pragma once

#include "../JuceLibraryCode/JuceHeader.h"
#include "PluginProcessor.h"


class PluginParameters : public AudioProcessorParameterWithID
{
public:
    PluginParameters(const String&, 
		     const String&, 
		     const String& = String(), 
		     Category = AudioProcessorParameter::genericParameter);

   ~PluginParameters();

   float kickLevel;

   static const String kickLevel_Name, kickLevel_Label;
   
   AudioProcessorParameterWithID* pKickLevelParam;

   void putToXml(XmlElement& xml);
   void getFromXml(XmlElement* xml);
}

PluginParameters.cpp

#include "../JuceLibraryCode/JuceHeader.h"
#include "PluginParameters.h"

const String PluginParameters::kickLevel_Name = "kickLevel";
const String PluginParameters::kickLevel_Label = TRANS("Kick Level");

PluginParameters::PluginParameters(const String &parameterID,
	                           const String &paramName,
	                           const String &paramLabel,
	                           Category category) :
AudioProcessorParameterWithID(parameterID, paramName, paramLabel, category)
{
    kickLevel = 0.5f;
    pKickLevelParam = new AudioParameterFloat(kickLevel_Name, kickLevel_Label, 0.0f, 1.0f, kickLevel);
}

PluginParameters::~PluginParameters()
{
    pKickLevelParam = nullptr;
}

void PluginParameters::putToXml(XmlElement& xml)
{
   xml.setAttribute(kickLevel_Name, kickLevel);
}

void PluginParameters::getFromXml(XmlElement* pXml)
{
   pKickLevelParam->setValueNotifyingHost((float)pXml->getDoubleAttribute(kickLevel_Name));
}

Probably, I think, the problem is the way I’m using the *pKickLevelParam pointer, I’ve also tried using the & operator instead but it caused other errors.
Don’t know how to get out from this loop, I’m freaking out :smiley: .

Any help would be appreciated, thanks.

2

My 2 cents…use the AudioProcessorValueTree class. It’s worked well for me, and I’m sure, many others. Don’t reinvent the wheel if you don’t have to…especially if you’re relatively new to C++.

2 Likes
3

Can you elaborate on that? My gut feeling is, that it will be easier to sort these out (on whichever end they are) instead of reinventing the AudioProcessorParameters…

1 Like
4

There have been some recent APVTS improvements:

Please let us know what’s not working for you.

1 Like
5

Thanks to all of you!
The suggestion I received was from a pro developer and of course I trusted him…I just don’t wanted to rewrite all the parameters’ code in the future, using something stable since the beginning, but for now avoiding the ValueTree just slowed down my workflow.
I think i’ll try to get back to the ValueTree approach, so I can focus on the other problems (this VST is gonna be a huuuge thing I guess).
If something goes wrong I’ll certainly let you know!