Hello everybody and happy new year.
I would like to have on my AudioProcessorEditor a graphic element to visualise when the plugin has received a noteOn message.
I would like to now what it would be the best practice to do so, as in many other threads I have understood that it is not a good idea to send data from the processor to the editor.
So, I think that having a callback for an editor custom function triggered by a noteOn message in the midiBuffer would not be a good idea.
but I can’t imagine another solution, so I am little bit stuck.
thanks for your help.
d
For such things I usually set an atomic value in the processor, and in my editor I check that value in my timer callback. (For booleans that I need to reset, such as an indicator to take an action once, I use an atomic boolean and call exchange(false) on that from the editor’s timer callback.)
2 Likes
thanks for the quick reply Howard! how fast should be the timer call-back to not miss any message?
It’s likely impossible for the editor to guarantee that the editor is able to query a value from the processor before the processor potentially makes another change to the value. You’re not in control of how often MIDI events happen, and your editor shouldn’t hog all the system resources and time trying to wait for the exact moment something happens in the processor.
You don’t say what information the processor needs to give to the editor, or what that indicator in the editor would do when a noteOn happens. (Or if you need to know when a noteOff happens, or if the note number matters, etc.)
If you just want to briefly flash an LED when a noteOn occurs, for example, then you don’t care if more than one noteOn happened since you last checked. Only the fact that one happened since you last checked matters.
If you DO care if more than one noteOn happened, but don’t care about the specifics, then you’d need something like a counter instead of a single boolean. The processor would increment the counter, and the editor would (likely) swap(0) to reset the counter to 0 when getting the current count.
If you need specifics about ALL the noteOns (and possibly about the noteOffs) that happen, then you’ll need a lock-free FIFO to push them into a queue from the processor and pull them from there in the editor’s timer callback. That’s a little too detailed for me to outline the steps for right now, but that’s the general method, I think.
2 Likes
Why not using listeners?
Like the editor listens to the processor, and when it gets synchronously notified it posts a message using callAsync? Is it that bad?