Table of Contents
This tutorial illustrates how to handle MIDI input events. In addition to handing MIDI data from an external source, an on-screen keyboard component is introduced.
Platforms: Windows, Mac OS X, Linux
Download the demo project for this tutorial here: tutorial_handling_midi_events.zip. Unzip the project and open it in your IDE.
If you need help with this step, see Tutorial: Getting started with the Projucer.
- Ideally, you should have an external MIDI source attached to your computer. Failing this, some kind of virtual MIDI source (that create virtual MIDI ports on the computer) would be helpful.
The demo project presents an on-screen MIDI keyboard and allows the user to select one of the hardware device MIDI inputs using a combo-box. MIDI events received from either of these sources are displayed in the lower part of the window. This is shown in the following screenshot:
This tutorial demonstrates how to handle MIDI input in a basic application. JUCE makes it easy to discover the list of connected hardware MIDI interfaces. It also provides the MidiKeyboardComponent class that allows you to display an on-screen keyboard. First, let's look at the member variables in our
- : We use the AudioDeviceManager class to find which MIDI input devices are enabled.
- : We display the names of the MIDI input devices in this combo-box for the user to select.
- : This is used to de-register a previously selected MIDI input when the user selects a different input.
- : This flag is used to indicate that MIDI data is arriving from an external source, rather than mouse-clicks on the on-screen keyboard.
- : The MidiKeyboardState class keeps track of which MIDI keys are currently held down.
- : This is the on-screen keyboard component.
MainContentComponent constructor we intialise , , and . We also take a note of the application start time so we can display the MIDI data timestamps relative to this.
We must pass a MidiKeyboardState object to initialise the MidiKeyboardComponent object. And, since these are statically allocated objects the MidiKeyboardState must be listed first in our member variables.
If the user changes the selected MIDI input then the
comboBoxChanged() function will be called:
setMidiInput() function makes our application start listening to the selected device. It also enables the device if it is currently disabled:
scopedInputFlag variable makes use of the ScopedValueSetter class. This does the following:
- It stores the current state of the
- It sets the
isAddingFromMidiInputmember to true.
- When the function exits it reset the value of
isAddingFromMidiInputmember to the state it was in at the start of the function.
MainContentComponent constructor the MidiKeyboardComponent object is added to our
MainContentComponent parent component and made visible. We also listen to the MidiKeyboardState object (not the component):
The MidiKeyboardStateListener class has two pure virtual functions that we must implement. These are the MidiKeyboardStateListener::handleNoteOn() and MidiKeyboardStateListener::handleNoteOff() functions.
Here you can see how the
isAddingFromMidiInput member is used. This prevents events that arrived from the hardware input from being posted to our list more than once.
postMessageToList() function may look a little unusual at first:
IncomingMessageCallback class is a subclass of the CallbackMessage class. We need to use this since we can't be sure from which thread the
postMessageToList() function will be called. It will be called from the message thread if the user clicks on the MidiKeyboardComponent object. But, if the data arrives from an external MIDI source then it will be called from the background MIDI thread (possibly an operating system thread).
The CallbackMessage class provides a means of calling a function on the message thread. The CallbackMessage class is a kind of ReferenceCountedObject class. This is why we don't (apparently) need to store the
IncomingMessageCallback object anywhere. In fact, the
IncomingMessageCallback::post() function (which is the MessageManager::MessageBase::post() function) adds the object to a queue that is handled by the MessageManager class. The MessageManager class will eventually find this object in the queue and call the
IncomingMessageCallback::messageCallback() function on the message thread. Once this function has been called, the
IncomingMessageCallback object will be deleted. Thus the lifetime of this object is handled (almost) automatically.
- This is only really necessary since we need to send the data to the message thread. It is likely that some kind of inter-thread communication is necessary in a MIDI application but the exact implementation depends on the circumstances.
getMidiMessageDescription() functions are very similar to these functions from Tutorial: The MidiMessage class. The main difference is that we make a note of the source  of the MIDI message (which hardware input, or the on-screen keyboard):
- Add some sliders to the user interface that transmit and respond to messages such as modulation wheel (CC1) and pitch wheel.
This tutorial has introduced some classes for handing and displaying MIDI input events. In particular you should be able to:
- List the available MIDI input devices.
- Create a menu of MIDI input devices.
- Listen to MIDI arriving at a hardware input.
- Display MIDI note data using the MidiKeyboardComponent class.
- Post messages from other threads to be be dealt with on the message thread using the CallbackMessage class.
Generated on Fri Jan 12 2018 09:51:15 for JUCE by 1.8.13