Audio plugin wrappers improvements

Hi,

I’m wondering if their is a plan to add the next list of features in Juce?
I’ve already written the code for it and I use it in all my plugins.
I propose it because I find those ideas general enough to be included in the Juce audio plugin SDK. So maybe…

New Classes & method:

  • Audio Plugin parameter class with properties as “unit” (%, Hz, dB, generic, …), “type” (boolean, continuous, discrete, indexed, …), min, max, skewFactor, precision, automatable, progression type, color, string value, …
  • A way to store a list of these parameters in the AudioProcessor.
  • A way to store a preset (a set of theses parameters’ values), and to undo/redo preset loading in the processor.
  • Any ideas around presets, as dialog boxes to save/restore presets in the processor, presets morphing, …

Wrappers suggestions

  • Thanks to the previous methods, AudioUnit compliance could be full: generic view respecting parameters type (some hosts only have the generic view, no custom UI)
  • The RTAS wrapper could handle parameter colors in PT: red for write, green for read, …
  • Native AU and RTAS elements be used in wrappers as kAudioUnitParameterUnit_Hertz, CPluginControl_Discrete, kAudioUnitParameterFlag_DisplayLogarithmic, …
  • Writing automations in the host would then be correctly displayed: drawing with correct values and units, and not just a float varying from 0 to 1.
  • ProTools AS support: the RTAS wrapper just needs to be slightly modified for it, so is their a reason to avoid it?

If their is any interest in this, I could post my code after some adaptations.

Helori

Sure !
It seems actually everybody is doing it’s own stuff to handle parameters, automation, presets, undo/redo etc…
A juce solution would be great.
Protools AS would be great, but still not as much as AAX :slight_smile:

Salvator

I think there will (or at least should) be a major overhaul of the plugin wrapper this year, with AAX, VST3, sidechaining and a few minor things like those mentioned in the OP. Now everybody seems to be cooking up their own stuff, but since this class is really central to JUCE I guess it’s wisest if Jules rewrites it himself. If it’s foreseeable though that this can’t be done in 2012 due to time/workload constraints then we should probably make an effort as plugin developers and try to channel the various existing private wrappers into an official version. Jules, what do you think?

Anything that you guys can think-through for me in advance would be awesome! My brain only has a finite number of cores, are currently all busy on GL, android, modules and introjucer stuff, but when I get some free capacity again I’ll be diving into plugins, trying to have a big push to add all the new requests. So at that point, if there was a bunch of clearly thought-out requests or example code to get me started, that’d be a huge help!

I would like to know if someone still wants to share it own implementations of audio plug-in wrapper improvements, so they will be included in JUCE :wink: This way, Jules won’t have to code that himself, and the functionnalities will be available sooner

Thanks in advance !

I really think such parameter system really needs to be embed in Juce !
We’re all doing our own stuff and probably gathering all good ideas would end up with a powerfull system.

Personally here’s what I’m doing :
All my parameters are stored in a .csv text file that I can open in Excel as spreadsheet.
In Excel I can edit my parameters in the table in a very human way :

ID Name Description Min Max Default Unit Decimal Type
0 Gain Output Level -12 12 0 3 float dB

then I embed that .csv into my code as Binary and have a class called ParameterManager which load that file :

and this ParameterManager then handle everything I need. Here’s some examples :
int getNumParameters(); float getValue (int index); bool setValue (int index, float newValue); float getHostValue (int index); bool setHostValue (int index, float newHostValue); float convertFrom01 (int index, float val); float convertTo01 (int index, float val); float getDefaultValue (int index); float getMin (int index); float getMax (int index); String getType (int index); String getParameterName (int index); String getParameterDescription (int index); const String getParameterLabel (int index); const String getParameterText (int index); const int getParameterIDFromName (String name); const XmlElement* saveBank(); void loadBank (XmlElement* bankToRecall); etc...

it can handle bool, float, stepped parameters (like “small || medium || large”), etc…
This means that in my PluginAudioProcessorEditor code, I only have a few lines for ALL my sliders (or buttons, comboboxes…) :

void PluginAudioProcessorEditor::sliderValueChanged (Slider* sliderThatWasMoved)
{
    paramID = filter->parametersManager.getParameterIDFromName (sliderThatWasMoved->getName());
    if (paramID != -1)
    {
        //shortcut to default a knob (alt+click)
        if (ModifierKeys::getCurrentModifiers().isAltDown())
            sliderThatWasMoved->setValue(filter->parametersManager.getDefaultValue (paramID));
        //then send parameter change to processor
        float value = filter->parametersManager.convertTo01(paramID, (float) sliderThatWasMoved->getValue());
        filter->setParameterNotifyingHost (paramID, value);
    }
}

and to update the UI :

void PluginAudioProcessorEditor::updateParametersFromFilter() { for (int i = 0; i < getNumChildComponents(); i++) { Slider* slider = dynamic_cast<Slider*> (getChildComponent(i)); if (slider != nullptr) { //-------------update State of all Slider's-------------- int paramID = filter->parametersManager.getParameterIDFromName (slider->getName()); if (paramID > -1) slider->setValue(filter->parametersManager.convertFrom01(paramID,filter->getParameter(paramID)), dontSendNotification); } }

My template plugin now barely change for new plugins, and I just create and fill a new PARAMETERS.csv then name the sliders accordingly in Jucer. And when I update my ParameterManager class with new things (undo/redo, support for midi learn, log range etc…), all my plugins are improved at once.

There may be better ways and room for improvement, but this changed my life already…
Maybe someone would find some inspiration out of that.

Salvator

Thanks for sharing :wink: