MidiKeyboardState has two methods of interest for this posting, processNextMidiEvent and processNextMidiBuffer.
Both of them will call the state listener accordingly but this is not always desired, especially if you use it inside
a application that is not block based.
Would it be possible to have a flag to not call the listener as we have with the slider control e.g.:
void processNextMidiEvent (const MidiMessage &message, bool sendUpdateMessage);Thanks
Fine, but these methods don’t have such a Boolean right now so they would probably slip through 
I am fine with enums as long as they find their way into these methods of the MidiKeyboardState class.
Thanks
I just came back to this, but looking at the class, it doesn’t make any sense to me that you’d ever want to stop a listener receiving these events. If you did that, you could end up with stuck notes and all kinds of strange state problems. It’d also mean adding extra parameters to a whole bunch of methods, not just the one you mentioned… I think I’ll need some better arguments to convince me on this one!
Got your point but let me explain the situation. The KeyboardState class works best inside a block based application as
you can call its methods regularly and simply insert keyboard events if you want to. If you don’t have your app block based
and you only want to update the MidiKeyboard component then you’d have to call processNextMidiEvent which calls the listener.
So far so good but the listener is usually a Midi output or something like this and then it acts like a hard wired Midi Thru!
That means your output would have to filter out the events that came in from the Midi input and only send the events generated
by the MidiKeyboardComponent. The only solution I could figure out is to have a thread regularly passing a MidiBuffer
containing the events to display and to insert the events from the MidiKeyboardComponent. What a waste…
So what is actually missing is a way to only update the MidiKeyboardComponent.
Sorry, maybe I’m being a bit slow, but I really can’t see what you’re trying to do…
Just want the MidiKeyboardComponent to display a NoteOn/Off message (Key goes yellow) that came in
from a physical Midi input or whatever. The KeyboardState class as it is today ALWAYS calls its listener on such an event
and the listener is usually a Midi output -> We have a Midi Thru!!!
Bump
Sorry, don’t have the brain capacity to give this any thought at the moment.
Let’s get back to this. I was trying to get my head around this but couldn’t figure out how to use the MidiKeyboardState
inside a NON-block based application because I always face the “Midi Thru” problem. Why?
The KeyboardStateListener is used to generate Midi notes for a particular note that you may have clicked on the
MidiKeyboardComponent. That Midi note should be sent somewhere but mostly and unsurprisingly to a Midi output
device. So far so good. But if you receive a Midi note from an Midiinput, then you would normally pass it on to the
KeyboardState its processNextMidiMessage method to make the MidiKeyboardComponent acting on it (UI). Since
this will always notify the listener you will end up with the Midi Thru effect!
So from my point of view there is no better way than having a choice to notify the KeyboardStateListener or not
when you call processNextMidiMessage and of course processNextMidiBuffer.
Based on this I added a “sendNotification” argument to processNextMidiMessage and processNextMidiBuffer
and to the other internal class methods noteOnInternal and noteOffInternal.
Furthermore I added another callback to KeyboardStateListener, so called “stateChanged” that gets always
called (even if I don’t want to send a notification) and is used to force the KeyboardComponent to update.
In the hope I didn’t oversee something,
have a good one,
Joerg
