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!
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);
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()
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.
note that you can get the range like that:
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.
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.