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.
Level: Intermediate
Platforms: Windows, macOS, Linux
Classes: AudioDeviceManager, MidiMessage, MidiInputCallback, ComboBox, MidiKeyboardComponent, MidiKeyboardState, CallbackMessage, ScopedValueSetter
Download the demo project for this tutorial here: PIP | ZIP. Unzip the project and open the first header file in the Projucer.
If you need help with this step, see Tutorial: Projucer Part 1: Getting started with the Projucer.
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 MainContentComponent
class:
In the MainContentComponent
constructor we initialise [3], [4], and [6]. 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.
The combo-box containing the list of MIDI inputs is populated by getting the list of MIDI inputs connected to the computer from the MidiInput class using the MidiInput::getDevices() function:
If the user changes the selected MIDI input then the lambda function assigned to the ComboBox::onChange helper object will be called:
The setMidiInput()
function makes our application start listening to the selected device. It also enables the device if it is currently disabled:
We implement the MidiInputCallback::handleIncomingMidiMessage() pure virtual function. This updates the keyboard state (which in turn will update the MidiKeyboardComponent object):
Notice the scopedInputFlag
variable makes use of the ScopedValueSetter class. This does the following:
isAddingFromMidiInput
member.isAddingFromMidiInput
member to true.isAddingFromMidiInput
member to the state it was in at the start of the function.In the 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.
The postMessageToList()
function may look a little unusual at first:
The 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.
The addMessageToList()
and getMidiMessageDescription()
functions are very similar to these functions from Tutorial: Create MIDI data. The main difference is that we make a note of the source [7] of the MIDI message (which hardware input, or the on-screen keyboard):
This tutorial has introduced some classes for handing and displaying MIDI input events. In particular you should be able to: