Midi Keyboard Component

[sm_jamieson]

I know this has been revisited several times in the past, but *please* can we try to fix the Midi Keyboard Component. I’ve seen the messages on the JUCE forum regarding this. This issue is the only real niggle I have.
Issues are:

1.The keyboard does not indicate incoming midi note messages. I know this used to work but apparently with duplicate midi output, so I assume it was removed from ctrlr. I looked at the ctrlr and JUCE code but am currently unsure how ctrlr *prevents* the keys from responding to midi !
If it is not possible to have it working as an indicator and live keyboard at the same time, could we have a ctrlr option to choose which mode ?

2. The keyboard does not work with multi-touch. This is not a touchscreen issues. If you play the keyboard with the PC keys, you cannot play chords. This is probably a JUCE problem.

3. It would be useful to have the full PC to midi keyboard component key mapping facilities in JUCE available to ctrlr via the gui or Lua rather than just the start octave.

4. Presently the midi keyboard cannot be scaled easily in ctrlr since the start to end key *range* from JUCE cannot be set in ctrlr (the MidiKeyboardComponent::setAvailableRange routine in JUCE). Often the user would like the key range to match an 88 note keyboard rather than the whole 128 note midi key range.

3. I would like to also use the keyboard 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 note or ranges of notes to facilitate this. This is again probably a JUCE issue.

Thanks,
Simon.

[sm_jamieson]

On a previous post it was mentioned that the main requirement to fix item (1) is to know the source of the change in keyboard state, whether from a midi event or a gui key press. I’ve looked at the code in JUCE and the code paths are as follows:

keypress – noteOn – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)
and
processNextMidiEvent – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)

It should be simple for JUCE to pass the source (midi or GUI) through as an extra parameter in a variant of handleNoteOn. The comment on the JUCE forum about requiring two midi sources to the component seemed to kill the discussion dead, when what is actually required is much simpler.

Simon.

[sm_jamieson]

Regarding the item (1) comment “if it is not possible to have it working as an indicator and live keyboard at the same time, could we have a ctrlr option to choose which mode ?”.

I suggest a compromise.
Since the JUCE midi keyboard component keypresses produce output on only one channel, you can safely display incoming midi for the other channels (whilst being able to suppress duplicate messages) since you know those can only have come from midi input and not the GUI !

Simon.

[sm_jamieson]

I mentioned before that the code paths in JUCE are:

[keypress on GUI] – noteOn(chan,note,vel) – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)
and
processNextMidiEvent – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)

Regarding the current ctrlr code:
Since noteOnInternal sets the note state that is used when drawing the keyboard (in MidiKeyboardComponent::paint) I am note sure why the incoming midi is not being indicated on the keyboard in ctrlr. Something in ctrlr must be bypassing a part of the process. This will need investigating in ctrlr. It should not be necessary to call NoteOn from handleNoteOn in order to get the GUI to update ( thus generating a duplicate midi event – which I believe was the original problem).

Due to the move of ctrlr to GitHub, I cannot see the original code from the time when the GUI did indicate incoming midi but was seeing duplicate midi events, so I could not investigate further.

Thanks,
Simon.

[Author]

Posts