Optimize audio paramter update from audio thread

Audio Plugins
1

Hi,
currenlty I have a background thread running, that constantly checks for parameter changes within the plugin and processes them. The audio thread informs the background thread via variables. The background thread runs on lowest priority and has a sleep cycle of 50ms.
How can this be optimized? It would be interesting to learn, if there is a best practice how to handle it.

2

an aside: The best practice is for the DAW to provide a simple list of only the parameters that changed.
The list is typically empty on most calls to processBlock, and only contains entries when you are changing a parameter on the GUI for example. This is far more efficient then ‘polling’ (constantly checking all the parameters just-in-case).

This approach is supported by VST3, AU, CLAP and AAX.
It’s about time JUCE supported it.

3 Likes
3

Are you talking about parameter changes in the host that are reported to the plugin? I’m looking for a solution for the other direction, reporting parameter changes in the plugin to the host. Or is this a bidirectional solution like the audio and MIDI buffer? And of course I’m looking for a solution that is possible with the current JUCE version.

4

I’m confused. What do you mean by that statement? Your last comment said you wanted to know about reporting parameter changes to the host. When your parameters are changed, are they not notifying the host already? Normally parameters are changed via setValueNotifyingHost(). So if the parameter has changed when you’re checking it, the host should already know this, because it was notified when the parameter was changed.

5

I have a scenario, where an audio parameter can change through code in processBlock. When this happens, I don’t inform the host about the change on the audio thread. I just store the new parameter value in a data model. The background thread recognizes the change and calls setValueNotifyingHost. I read on this forum in the past, that one should avoid to call setValueNotifyingHost on the audio thread by any means. So I went for the background thead solution.

1 Like