Hi all,
I know it’s been discussed before, but I just stumbled upon it today. The docs for AsyncUpdater suggest “Don’t use it with the real time thread”. But I come across real time usage inside use all the time. My newest discovery: inside the ParameterAttachment. Is that on purpose or should that be changed?
Best, Rincewind
AsyncUpdater shouldn’t be used in the audio thread. And I think that ParameterAttachment is a class designed to be used in the message thread, judging by its constructor description, where it states “The function that will be called on the message thread in response to parameter changes”, or the UndoManager argument.
I consider all the cases you mention bugs.
ParameterAttachment’s usage of AsyncUpdater could cause locks and allocations if the callback happens from the audio thread (which is the case often).
It would be great if it switched to using a safe method that doesn’t do that, using a timer that polls the parameter value instead of triggering the async callback directly.
Thanks for the input. That’s what I was thinking. It would be great if there was a JUCE class to handle that busy pull loop. Though an example would be in the GenericAudioProcessorEditor.
Actually, it might be worth a thought to make this configurable for parameter attachment. I just noticed that I never change the parameter from the audio thread. The audio graph always use the parameters as read only (in my case!), so using async updater is perfectly fine (and possibly better for performance).
You might not change the parameters in the audio thread, but many hosts certainly will. ParameterAttachment handles that by switching depends on thread anyway. It just should change the method for the audio thread case, in my opinion.
I’m developing a host application and there are a lot of slider attachments that can’t and never will be changed by the audio thread. Starting a timer for every single slider and button would have a serious performance penalty.
But I get that it is more common to have a few controls that might or might not be controlled from a real time thread with midi automations. So that should definitely be the default.
You can definitely optimize the timer so it’s a single (static) timer that has an atomic bool that only gets set if any of the parameters changed, and otherwise do nothing. That’s what I do in my ParameterAttachment class and there’s no penalty even for thousands of parameters.
Hm, you are right, haven’t thought of it that way. I was just picturing the GenericAudioProcessor solution.
@juceteam anything from your end on the usage of AsyncUpdater in the ParameterAttachments?
The problem is in void ParameterAttachment::parameterValueChanged ( int , float newValue)
where the async update might be scheduled from the audio thread (e.g. by MIDI Automation).
It would work like this: The parameter attachment listens on the AudioParameter. The AudioParameters value gets changed by the audio thread and it calls all listeners on that said thread.
