Sending change via ChangeBroadcaster every audio processor callback performance

Is there any performance drawbacks from using a ChangeBroadcaster to notify editor elements that a change has occurred almost every processor callback? Being that the processor is called many, many times per second (or could be), I wonder if there is any performance issues with that.

My reason for this is to replace the need of using the Timer class to refresh the editor every update, for example in use of an amplitude meter. Though this — in best practice — is capped to 60 hz, so unfortunately monitors with a greater refresh rate do not benefit. My thoughts is sending a change every processor can make the motion smooth for any monitor.

You are incurring extra overhead in your processor callback, and unless it is absolutely needed, that should be avoided. And, since the Change callback is async, and happens on the message thread, just like Timer, why not just increase the timer rate (which can have a different rate than you refresh rate).? which gets you more updates, but does not add more cpu cycles the audio processing thread.

What is data that you want to update in the UI? audio data? or some POD like an int or float?

I’ve seen multiple times on this forum that the use of ChangeBroadcaster (Broadcaster) in the processor to notify change is perfectly acceptable (see From processor to editor). How would sending change via ChangeBroadcaster every processor block be different than just sending change once every four processor blocks?

For my case, an array of structs I have. Though regardless of type, the change broadcaster simply tells the destination that it should look at the processor’s data again (via a pointer) and update the UI accordingly (see Singleton instance shared between plugin instances).

Anything that works on the message thread won’t do better than a Timer, and if you’re using the software renderer, painting itself has the same limitation. Bear in mind that you already have a granularity dependent on the block size. Large blocks can make visualizations a bit unsteady -there’s not much you can do about it.