Please make AudioProcessorValueTreeState::Parameter public!

General JUCE discussion
1

Why is it so hard and sometimes even impossible to extend the Juce framework without breaking it?
I am currently struggeling hard to implement a couple of urgently needed GUI features and it seems like that is not how the Juce framework is meant to be used.
At the moment I need to create a couple of custom Attachments to couple my own GUI widgets with the AudioProcessorValueTreeState parameters.
Since the Parameter class is private I see no option other than changing the framework code.

I have now made the Parameter class public and have moved the definitions of both Parameter and AttachedControlBase to the header file. I could not find any other way to implement my own attachments.

I rather would not change the Juce code. Is there a recommended way to implement Attachments without that? Thanks for any suggestions!

1 Like
AudioProcessorValueTreeState && thread-safety
2

For what do you need the Parameter class exactly?

I just pass the paramID to my “attachements”, and then simply get the AudioProcessorParameterWithID. that was enough for what i needed :
AudioProcessorParameterWithID* param = audioProcessorValueTreeState.getParameter (paramID);

3

Here is my problem: The gui widget works with unnormalized values while AudioProcessorParameterWithID only knows normalized values (0 … 1)

I don’t see how I would translate or scale the unnormalized value that I get from the gui widget into a normalized parameter value and vice versa without access to the Parameter::range object. (or how to avoid the translation in the first place)

These are the Parameter members that i need to access and that are not available from AudioProcessorParameterWithID:

  • void Parameter::setUnnormalisedValue(float newUnnormalisedValue)
  • static Parameter* getParameterForID()
  • Parameter::range
4

The whole point of this thing using a ValueTree is you don’t even need to care about the parameter objects directly - you can just interact with and change the ValueTree, and those changes will magically get sent along to the processor.

As for converting ranges, there are lots of non-intrusive ways of converting a number! You could attach a Value with a custom ValueSource to the tree, or just make your GUI component deal with it differently.

5

note that you can get the range like that:
audioProcessorValueTreeState.getParameterRange (paramID)

1 Like
6

Cool! This would be the missing piece to allow for the creation of a fully fledged external Attachment. On the other hand there is already an existing environment that could be used if it only were public. I have the impression that I am often required to reimplement a functionallity that is already present in the framework but can not be accessed.
Since the user of the framework is able to invent her own controls I feel that there should also be an easy way to make a fitting attachment for each control.
There is also room for improvement of the existing attachments. Here is my attempt for a ComboBoxAttachment. it allows

  • to populate the Itemlist on instantiation without any additional effort based on the properties of the Parameter.
  • to insert alternative text representations of the Parameter value as text input.

I am still not sure how this could be achieved conviniently without modifying the framework.
I’ll try that tomorrow using ::getParameterRange(paramID). If it comes out nicely I’ll modify my examples to work with the unaltered framework.

1 Like
7

I have now decided to use the perfectly fine environment that Juce already comes with. Of course it is is inaccessible (at the moment). Still in my situation I find it preferable to fork the framework and move a bit of existing code around to make it accessible instead of reinventing the wheel.