Imagine a class for skinning plugins by dev and users - would it look like this?

[anoesisaudio]

Ok, so I left a cryptic agreement to something that was not really the subject in this thread -

Update AudioProcessorValueTreeState from process block

Just making a little kick drum VST, and have set it all up with the lovely new AudioProcessorValueTreeState class, and have connected my UI with AudioProcessorValueTreeState::SliderAttachment classes. …And that all works nice and well. State of the sliders is saved in the host, and recalled fine when reloading. But i’m getting stuck with this: I want to update the ValueTreeState and also the pitch slider, whenever a midi note is entered. Here’s what my processBlock looks like: MidiMessage …

I would like to build something to make skinning easier. Initially I thought about writing a class (e.g. AudioProcessorEdtorValueTreeState) which would be owned by whatever gui component to be used to actually do the editing (like processor owns AudioProcessorValueTree).

But it may make more sense to have a custom lookandfeel class own the parameters that are used to alter the way the gui bits look (well, and feel).

I imagine its basis to look something like what is below, but I know some of you have done similar/better things. Am I way off the mark?

---

//==============================================================================
class ExLaF : public LookAndFeel_V3
{
public:
ExLaF() {}
~ExLaF() {}
void drawRotarySlider (Graphics& g, int x, int y, int width, int height, float sliderPos,
float rotaryStartAngle, float rotaryEndAngle, Slider& slider) override
{
// some new stuff - using variables retrieved from a ValueTree
}

private:
// skin parameters and undo manager - similar in use to AudioParameterValueTree use in processor
UndoManager lafUndoManager;
AudioProcessorEdtorValueTreeState lafParams;
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (ExLaF)
};

Thank you!

[daniel]

That’s possible, if you want to go into that detail. But I would recommend, not to retrieve the values from the draw routine, but to cache the variable in the LaF instance that you are holding anyway. You need to add an update method, whenever the valueTree changes.

Another approach, if you want to place the gui components, then I created a module for you:

ffAudio/ffLayouts

Here you can define placements of components in a ValueTree, which places the gui elements according to the size. It features nested horizontal and vertical layouts, size constraints like min and max sizes, proportional factors (stretch) and also groups of knobs/components displayed by GroupComponent.

A XML-Editor to edit layouts is also available, but a little work in progress…

I actually wanted to add the definition of Drawables in the ValueTree, but I got stuck using the ComponentBuilder…

Maybe this is something to think about, let me know, if you have suggestions to improve…

[anoesisaudio]

Thanks Daniel - I will have a look.