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

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).