i’m using the MidiKeyboardComponent for two purposes
to represent icoming MIDI events, those events are coming from a MIDI device
to send MIDI evens based on mouse/keyboard input from the user
Problem:
When an event arrives on the MIDI device it’s added to the MidiKeyboardState by processNextMidiEventCall(), this state is linked to the MidiKeyboardComponent and the GUI updates. But since my class is also the MidiKeyboardStateListener, the handleNoteOn/Off calls get called and my class transmits MIDI data, the same way it transmits data when the mouse or keyboard is used to “press” the onscreen keys. So i get two noteOn/noteOffs instead of one: one comes from my code that is the listener of the state, the other comes from the MidiKeyboardComponent that is also the listener of the same state.
What’s the way out of this ? I thought i could maybe tell the MidiKeyboardComponent explicitly when to paint some noteOn events, but there is no interface to that (or at least i don’t see any other then injecting noteOn events to the MidiKeyboardState), i could do that since my callbacks on incoming MIDI data is async and i can safely interact with the GUI. Is there some other way i could do this ?
As atom mentioned here this causes real issues. Is there any word on this, Jules?
It’s kinda like JUCE has been spilt all over my MidiKeyboardComponent.
I forget the details of how those classes work, but there’s an example in the demo plugin where it shows the incoming events and also allows the on-screen keyboard to be used, and that works, doesn’t it?
Yes with one source of data, one MidiKeyboardState in the AudioProcessor, but what if have 2 sources, in my cases i need to process the events from the MIDI device (noteOn/Off messages) and the GUI generated MIDI events. But in both cases i can use only one MidiKeyboardState so i don’t know where did the perticular MIDI event come from, handleNotOn has a pointer to the MidiKeyboardState but it’s always the same one, since you can’t set more then one.
I need to know if the event is generated from the GUI or did come from somewhere else, i need to do that in handleNoteOn and handleNotOff callbacks.
Can we revisit this at some point. The MidiKeyboardComponent has a few issues. Some of the issues are:
1. It is often a requirement to use the component to both produce midi output and to indicate midi input. It is hard to do this as a MidiKeyboardStateListener since the handleNoteOn / Off methods do not specify the source of the keypress but the two causes of a change in keyboard state often need to be dealt with differently. The source of the event could be passed through in addition to the channel, note and veolocity. The usual way to handle this is to pass though an event object, to which extra information can be added without effecting the API.
2. Whilst JUCE in general handles multi-touch screens (you can move two sliders at the same time), the MidiKeyboardComponent itself does not work with multi-touch. This is not just a touchscreen issue - if you play the keyboard with the PC key mapping, you cannot play chords, although sustaining notes are able to sound at the same time.
3. Another good use of the component is as a indicator of keyboard zones, with different zones colour coded. It would be useful to be able to specify the colours of each individual notes or ranges of notes to facilitate this.
Not sure I agree that the MidiKeyboardState methods should incude a source, as the whole idea of the midi keyboard comp is that it'll behave like any other type of keyboard. But what exactly are you suggesting should be added to the methods?
It can definitely handle chords when you play it with a normal computer keyboard, I do that all the time! Also, the MidiKeyboardComponent specifically handles multi-touch events, and uses the incoming touch number as a finger number. Maybe something else is causing your problems there?
And you can draw the keys any way you like by using a LookAndFeel, or just overriding methods like drawWhiteNote.
I have come to JUCE via the ctrlr.org project and this issue is in relation the original post by atom on this thread. The original post on this thread describes the problem from the point of view of ctrlr.org. I have used Cantabile VST host which has a midi keyboard which appears suspiciously like a JUCE component, so I will see if that supports multitouch and chords.
Some of the issues I have seen may be due to problems in the ctrlr.org codebase, and I appreciate and understand your reply regarding painting the keys.
The original problem was how to draw the key in a "down" state without calling noteOn() from handleNoteOn(), and thus generating a duplicate midi event. I've looked at the code in JUCE and I think the code paths are as follows:
[keypress occurs on GUI] ? noteOn(chan,note,vel) ? noteOnInternal(chan,note,vel) ? handleNoteOn(chan,note,vel)
and
processNextMidiEvent ? noteOnInternal(chan,note,vel) ? handleNoteOn(chan,note,vel)
Since noteOnInternal sets the note states that are used when drawing the keyboard, the keyboard should indicate GUI actions and incoming midi. So I am not now sure what the problem in ctrlr.org actually is. I will have to follow it up there. Thanks for the response, I will post back if any other JUCE issues arise.
The multi-touch on a Windows PC definitely does not work in the MidiKeyboardComponent. In fact, if you try it enough times with two fingers you'll get a crash.
I had the same multiple notes problem and had to write a hack that determined what to do with the event based on the source, MIDI keyboard or MidiKeyboardComponent.
