Need a parameter+attachment scheme for non-"published" values

Feature Requests
1

We would love to see a way to use attachments for controls like Sliders to communicate round-trip, in a thread-safe manner, with parameters (or some other mechanism) in the processor, without making them visible to the hosts.

It’s been suggested that we write our own parameter sub-classes which expose the “is automatable” flag to the hosts. However, some hosts simply ignore that flag. Indeed, that appears to be the reason that that flag is not settable at all when using the newer parameter types (AudioParameterBool, etc.). So at best that this a partial solution, and one that JUCE designers did not think was a good idea when writing these parameter classes.

There is a new ParameterAttachment class in JUCE 6, which we had hoped would resolve this issue, but the change notifications that get sent, while avoiding the APVTS itself, still require setting a pointer to the processor and a parameter index, because the processor looks up the parameter by index (not by ParameterID), rather than responding via a callback (like parameterChanged()), which uses the ParameterID. That makes them visible to hosts, and those that ignore the flag allow users to automate them (which can cause major problems).

So, what we’ve had to do is implement each non-automatable “parameter” as an atomic in the processor, and use our idle timer callbacks in the editor and processor to handle update requests and notifications. But that means creating our own Listeners, and handling each of these “parameters” separately, with no way to simply add a ParameterAttachment to our controls.

What we’d really like is a way to make it as simple for controls to connect with the processor to handle requests to update those parameters (sent from the UI) and to broadcast changes to those parameters (to the UI, and to any attachments that exist there) as it is to do with regular parameters added to the processor class.

Like I said, I’ve written the code to do that for a few specific values that used to be non-automatable parameters, but it would be great if we could create them as parameters, but add them to some other list of “unpublished” parameters, and let the processor and editor and attachments handle the behind-the-scenes communication (in a thread-safe way).

2

Hi, I have the same issue.
I thought I found a workaround but in fact it doesn’t work as expected.
With a plugin with a lot of parameters that are not relevant to be automated, this is a serious issue.
Would be great if a solution would be implemented.

3

For this scenario, just create & use parameters like you normally would, but add them to a dummy processor instead of your real processor.

3 Likes
4

Thanks for the suggestion, I’ll try to workaround this way. I’ll have to rework some logics because I imagine i’ll no longer be able to rely on parameter index attribute as an identifier.
The trouble is that parameterValueChanged callback only uses parameterIndex. Not as simple as it looked first…
I’ll also end up with two distinct AudioTreeStates with a lot of impacts everywhere in my code, begining with I/O.
Definitly I’ll think twice before going. There’s indeed some lack in the framework.

5

we just need a second “private” tree for this, and we need to disconnect it from the host.
Would that be hard to make? I guess not!
The gesture() mechanism then also can facilitate 2 way communication.

6

My problem is due to existing code, and to keep I/O compatibility. If I did it from scratch sure it would be much easier.
It not impossible though, but not that obvious, I have to break many things, at least more than I expected.
To give an example, in many lists I’ll end up with distinct parameters with same index, impossible to distinguish when the parameterValueChanged(index) is called.

7

what can be helpful, is when you can have a parameter that behaves exactly the same as a regular one, but is tagged “private”. i.e. the DAW never hears about it. Although it does get stored in the presets.

That might be a good feature for JUCE in future.

It is also useful to have parameters that can be more than only floats. For example filenames. Other wise you end up having to virtually recreate the parameter system’s functionality (load/save/notification/thread-safety) yourself to cope with these cases.

3 Likes
8

that would mean that juce has to actively hide params from the host, since the hosts are not conforming to the standard for hiding, which the OP also mentioned.
And yes: string support should be added.

9

yeah, It’s not a case of telling the DAW “don’t automate this”. It’s more a case of just not telling the DAW at all about that parameter, and not notifying the DAW when it changes etc. Just handling it internally.

5 Likes
10

Yes, that’s exactly the need !