Non-automatable parameters and UI attachments?

HowardAntares · April 9, 2020, 8:21pm

I’ve read here that, for non-automatable parameters, it’s better to simply not add a parameter to the AudioProcessorValueTreeState object than to create a sub-class that overrides isAutomatable(), because DAWs may totally ignore that flag. Ok, I get that (for some DAWs, anyway).

But then how do I attach a UI object to the parameter? The various attachments, such as SliderAttachment, use the APVTS to link the Slider to the parameter, including its range and current value, making it much easier to control the slider and set the parameter from it.

Is there another convenient way to tie a parameter and a Slider together, if I can’t make the parameter non-automatable?

In the past, we’ve always been able to set parameters as automatable, meta, discrete, and/or binary, via the constructor for the parameter. But now I don’t see how to do any of this. Why did we lose so much existing functionality? I want to update from JUCE 5.3.2 to 5.4.7, but I’m having trouble making my plugin behave the same way as it did under 5.3.2.

HowardAntares · April 9, 2020, 9:26pm

Assuming I now will have to roll my own connections between DSP-related (Processor member) values and UI objects, what’s the safest way (i.e., thread-safe way) to make those connections in each direction?

daniel · April 10, 2020, 10:03pm

An interesting one. So I added a class to my gui editor PluginGuiMagic to achieve that:

github.com

ffAudio/foleys_gui_magic/blob/develop/Helpers/foleys_AtomicValueAttachment.h#L40


#pragma once


namespace foleys
{


/**
 The AtomicValueAttachment allows to read from a Value in a thread safe manner.
 You attach to a Value and call get() to read the current value.
 */
template<typename T>
class AtomicValueAttachment : private juce::Value::Listener
{
public:
    AtomicValueAttachment()
    {
        internalValue.addListener (this);
    }


    /**
     Let the attachment refer to the value.
     */

Just use the Value.referTo (value) and use the Value::Listener to update the atomic.

HowardAntares · April 16, 2020, 6:30pm

Not sure I get exactly how to use this. I need to accomplish these things in a thread-safe manner:

Pass a value of some sort to the Processor which will update the DSP internals when a button is pressed, knob is turned, etc., in the UI, without causing the DSP to stall if the UI writes such a value change.
Update the UI when a change occurs in one of those stored values in the Processor component, such as when reading session or preset data, or when parameterChanged() causes a side-effect of changing one of these stored values, again without the DSP stalling due to the UI reading that data.

I see that I need to do this not just for a couple of controls that currently have attachments (that require parameters to use), but also for a menu selection that will change a DSP-required data item.

At a later time, I will also deal with passing/sharing more complex data, but for now I just want to replace my current use of non-automatable parameters in as simple and thread-safe a manner as possible. (I just don’t see exactly how to use that class above to accomplish those goals, sorry.)

reuk · April 16, 2020, 6:32pm

JUCE 6 includes new ParameterAttachment classes which connect parameters directly to UI controls without relying on an APVTS, which might be helpful in this situation.

HowardAntares · April 16, 2020, 6:38pm

Well, when 6 comes out and I can actually use it in production code, that will be nice!

DEADBEEF · January 2, 2021, 6:53pm

I think that the utility shared by @daniel could resolve your first concern but did you find a way to handle your second point?
I’m currently facing the same issue

HowardAntares · January 4, 2021, 4:04pm

I have not revisited that issue. We decided we wanted to continue using the old parameters in order to support full backwards compatibility with older (pre-JUCE) versions, which meant that all those non-automatable parameters are still visible by the host. Not my preference, but that’s where we left it.

Site navigation

Non-automatable parameters and UI attachments?

Further Information