Can AttachedControlBase become derivable?

Just a quick bump on this :slight_smile:

And another bump!


I’m in :wink:

We’re working on it :slight_smile:

Well, if you need any user-feedback … I have a good supply of it right now!

What else is involved besides moving it to the APVTS header file?

It’s not the nicest interface. I’m sure we can do better.

I don’t think anyone here would really care how nice the interface is, as long as it becomes derivable. I requested this almost a year ago. There are only a couple of other feature requests that have as many votes…

I don’t think that’s true; we get a lot of feedback from the JUCE community letting us know they value our thoughtful approach to API design. We’re not going to suddenly lower our standards.

How is what you already wrote for AttachedControlBase not up to JUCE standards? If it weren’t up to standard, it would have never made it into the framework… or is that not how things work in JUCE land?

The requirements are different for a class that is a private component with all uses predetermined + locked down, vs. a public component which might be used in ways we didn’t consider. Just because AttachedControlBase works for the three cases we have now (where users don’t even have to know it exists), doesn’t mean it will scale to more complex use cases.

Seeing as it doesn’t really work with radio button groups, I can see how you would feel that way.

I would also like to take the chance to say that parameterValueChanged can be called on the audio thread and so using triggerAsyncUpdate() is technically not realtime safe here for these attachments. More info here: APVTS Updates & Thread/Realtime Safety

More info here too:

Moving away from AsyncUpdater is something we’d like to do, but it will be a separate chunk of work. Figuring out a mechanism that doesn’t introduce significant compromises in performance or usability is difficult.

Tom what’s the downside of having a timer + queue driven audio thread messaging system that this can use and any user requirements for audio-thread to message thread notification?

Mmmm, actually - maybe there’s a risk of multiple threads writing though…

A timer is the simplest solution, but there are things to think about:

A timer per updater, a single timer for all updaters, what are the frequencies (or the frequency), is that user selectable, what impact does it have on performance for one updater, what happens if you have loads of updaters, how will this change event ordering…?

We’ll look at this, but I don’t want it to hold back making custom attachments easier to create.

Can we move the timer and asyncUpdater back to where it came from and talk here about a way how users can write their own Attachment classes?


Equivalent functionality has been added to the juce6 branch:

If you had previously voted for this topic in the Feature Requests category you can now use your votes elsewhere.