Web MIDI API

Some user agents have music devices, such as synthesizers, keyboard and other controllers, and drum machines connected to their host computer or device. The widely adopted Musical Instrument Digital Interface (MIDI) protocol enables electronic musical instruments, controllers and computers to communicate and synchronize with each other. MIDI does not transmit audio signals: instead, it sends event messages about musical notes, controller signals for parameters such as volume, vibrato and panning, cues and clock signals to set the tempo, and system-specific MIDI communications (e.g. to remotely store synthesizer-specific patch data). This same protocol has become a standard for non-musical uses, such as show control, lighting and special effects control.

This specification defines an API supporting the MIDI protocol, enabling web applications to enumerate and select MIDI input and output devices on the client system and send and receive MIDI messages. It is intended to enable non-music MIDI applications as well as music ones, by providing low-level access to the MIDI devices available on the users' systems. The Web MIDI API is not intended to describe music or controller inputs semantically; it is designed to expose the mechanics of MIDI input and output interfaces, and the practical aspects of sending and receiving MIDI messages, without identifying what those actions might mean semantically (e.g., in terms of "modulate the vibrato by 20Hz" or "play a G#7 chord", other than in terms of changing a controller value or sending a set of note-on messages that happen to represent a G#7 chord).

To some users, "MIDI" has become synonymous with Standard MIDI Files and General MIDI. That is not the intent of this API; the use case of simply playing back a .SMF file is not within the purview of this specification (it could be considered a different format to be supported by the HTML5 <audio> element, for example). The Web MIDI API is intended to enable direct access to devices that respond to MIDI - external synthesizers or lighting systems, for example, or even the software synthesizers that are built in to many common operating systems. The Web MIDI API is also explicitly designed to enable a new class of applications on the web that can respond to MIDI controller inputs - using external hardware controllers with physical buttons, knobs and sliders (as well as musical controllers like keyboard, guitar or wind instrument controllers) to control web applications.

The Web MIDI API is also expected to be used in conjunction with other APIs and elements of the web platform, notably the Web Audio API. This API is also intended to be familiar to users of MIDI APIs on other systems, such as Apple's CoreMIDI and Microsoft's Windows MIDI API.

Obtaining Access to MIDI Devices

requestMIDIAccess()

Promise requestMIDIAccess(optional MIDIOptions options )

When invoked, returns a Promise object representing a request for access to MIDI devices on the user's system.

Requesting MIDI access SHOULD prompt the user for access to MIDI devices, particularly if system exclusive access is requested. In some scenarios, this permission may have already been implicitly or explicitly granted, in which case this prompt may not appear. If the user gives express permission or the call is otherwise approved, the vended Promise's resolveCallback is invoked, as a MIDISuccessCallback (i.e., with a MIDIAccess object and a MIDIOptions object as its arguments. The underlying system may choose to allow the user to select specific MIDI interfaces to expose to this API (i.e. pick and choose interfaces on an individual basis), although this is not required. The system may also choose to prompt (or not) based on whether system exclusive support is requested, as system exclusive has greater privacy and security implications.

If the user declines or the call is denied for any other reason, the Promise's rejectCallback (if any) is invoked as a MIDIErrorCallback.

When the requestMIDIAccess method is called, the user agent MUST run the algorithm to request MIDI Access:

Let promise be a new Promise object and resolver be its associated resolver.
Return promise and run the following steps asynchronously.
Optionally, e.g. based on a previously-established user preference, for security reasons, or due to platform limitations, jump to the step labeled failure below.
Optionally, e.g. based on a previously-established user preference, jump to the step labeled success below.
Prompt the user in a user-agent-specific manner for permission to provide the entry script's origin with a MIDIAccess object representing control over user's MIDI devices. This prompt may be contingent upon whether system exclusive support was requested, and may allow the user to enable or disable that access.

If permission is denied, jump to the step labeled failure below. If the user never responds, this algorithm will never progress beyond this step. If permission is granted, continue the following steps.
success: Let access be a new MIDIAccess object. (It is possible to call requestMIDIAccess() multiple times; this may prompt the user multiple times, so it may not be best practice, and the same instance of MIDIAccess will not be returned each time.)
Call resolver's accept(value) method with access as value argument.
Terminate these steps.
failure: Let error be a new DOMError. This should be of type "SecurityError" if the user or their security settings denied the application from creating a MIDIAccess instance with the requested options, or otherwise it should be of type "NotSupportedError".
Call resolver's reject(value) method with error as value argument.

MIDIOptions dictionary

This dictionary contains optional settings that may be provided to the requestMIDIAccess request.

boolean sysexEnabled

This member informs the system whether the ability to send and receive system exclusive messages is requested or allowed on a given MIDIAccess object. On the option passed to requestMIDIAccess, if this member is set to true, but system exclusive support is denied (either by policy or by user action), the access request will fail with a "SecurityError" error. If this support is not requested (and allowed), the system will throw exceptions if the user tries to send system exclusive messages, and will silently mask out any system exclusive messages received on the port.

In the options parameter passed to the resolveCallback, this member indicates whether system exclusive is allowed on the MIDIAccess.

MIDIAccess Interface

This interface provides the methods to list MIDI input and output devices, and obtain access to an individual device.

sequence<MIDIInput> inputs()

Returns a list of the MIDI input ports available on the system. This list is not a live list (i.e., if a device is added or removed after calling getInputs(), the list is not changed.)

sequence<MIDIOutput> outputs()

Returns a list of the MIDI output ports available on the system. This list is not a live list (i.e., if a device is added or removed after calling getOutputs(), the list is not changed.)

attribute EventHandler onconnect

The handler called when a new port is connected.

This event handler, of type MIDIConnectionEvent, MUST be supported by all objects implementing the MIDIAccess interface.

attribute EventHandler ondisconnect

The handler called when a previously-available port is disconnected.

This event handler, of type MIDIConnectionEvent, MUST be supported by all objects implementing the MIDIAccess interface.

Whenever a previously unavailable MIDI port becomes available for use, the user agent SHOULD run the following steps:

Let port be the MIDIPort corresponding to the newly-available port.
Let event be a newly constructed MIDIConnectionEvent, with the port attribute set to the port.
Fire an event named connect at the MIDIAccess, using the event as the event object.

Whenever a previously available MIDI port becomes unavailable for use, the user agent SHOULD run the following steps:

Let port be the MIDIPort corresponding to the newly-unavailable port.
Let event be a newly constructed MIDIConnectionEvent, with the port attribute set to the port.
Fire an event named disconnect at the MIDIAccess, using the event as the event object.

MIDIPort Interface

This interface represents a MIDI input or output port.

input: If a MIDIPort is an input port, the type member MUST be this value.
output: If a MIDIPort is an output port, the type member MUST be this value.

readonly attribute DOMString id

A unique ID of the port. This can be used by developers to remember ports the user has chosen for their application. The User Agent MUST ensure that the id is unique to only that port. The User Agent SHOULD ensure that the id is maintained across instances of the application - e.g., when the system is rebooted - and when a device is removed from the system. Applications may want to cache these ids locally to re-create a MIDI setup. Some systems may not support completely unique persistent identifiers; in such cases, it will be more challenging to maintain identifiers when another interface is added or removed from the system. (This might throw off the index of the requested port.) It is expected that the system will do the best it can to match a port across instances of the MIDI API: for example, storing the port interface manufacturer, name and index in the id, and attempting to find any ports with that name to consider as a match. Applications may use the comparison of id of MIDIPorts to test for equality.

readonly attribute DOMString? manufacturer

The manufacturer of the port.

readonly attribute DOMString? name

The system name of the port.

readonly attribute MIDIPortType type

A descriptor property to distinguish whether the port is an input or an output port. For MIDIOutput, this MUST be "output". For MIDIInput, this MUST be "input".

readonly attribute DOMString? version

The version of the port.

attribute EventHandler ondisconnect

The handler called when a previously-available port is disconnected.

This event handler, of type disconnect, MUST be supported by all objects implementing MIDIPort interface.

Whenever the MIDI port corresponding to the MIDIPort becomes unavailable for use, the user agent SHOULD run the following steps:

Let port be the MIDIPort.
Let event be a newly constructed MIDIConnectionEvent, with the port attribute set to the port.
Fire an event named disconnect at the port, using the event as the event object.

MIDIInput Interface

attribute EventHandler onmidimessage: This event handler, of type MIDIMessage, MUST be supported by all objects implementing MIDIInput interface.

Whenever the MIDI port corresponding to the MIDIInput finishes receiving one or more MIDI messages, the user agent MUST run the following steps:

Let port be the MIDIInput.
If the MIDIAccess did not enable system exclusive access, and the message is a system exclusive message, abort this process.
Let event be a newly constructed MIDIMessageEvent, with the timestamp attribute set to the time the message was received by the system, and with the data attribute set to a Uint8Array of MIDI data bytes representing a single MIDI message.
Fire an event named midimessage at the port, using the event as the event object.

It is specifically noted that MIDI System Real-Time Messages may actually occur in the middle of system exclusive messages in the input stream; in this case, the System Real-Time messages will be dispatched as they occur, while the system exclusive message will be buffered until it is complete (and then dispatched).

MIDIOutput Interface

void send( sequence<octet> data, optional double timestamp )

Enqueues the message to be sent to the corresponding MIDI port. The underlying implementation will (if necessary) coerce each member of the sequence to an unsigned 8-bit integer. The use of sequence rather than a Uint8Array enables developers to use the convenience of output.send( [ 0x90, 0x45, 0x7f ] ); rather than having to create a Uint8Array, e.g. output.send( new Uint8Array( [ 0x90, 0x45, 0x7f ] ) ); - while still enabling use of Uint8Arrays for efficiency in large MIDI data scenarios (e.g. reading Standard MIDI Files and sending sysex messages).

The data contains one or more valid, complete MIDI messages. Running status is not allowed in the data, as underlying systems may not support it.

If the port is disconnected, throw an InvalidStateError exception.

If data is not a valid sequence or does not contain a valid MIDI message, throw a TypeError exception.

If data is a system exclusive message, and the MIDIAccess did not enable system exclusive access, throw an InvalidAccessError exception.

sequence<octet> data: The data to be enqueued, with each sequence entry representing a single byte of data.
optional double timestamp: The time at which to begin sending the data to the port (as a DOMHighResTimeStamp - a number of milliseconds measured relative to the navigation start of the document). If timestamp is not present or is set to zero (or another time in the past), the data is to be sent as soon as possible.

Examples of Web MIDI API Usage in JavaScript

The following are some examples of common MIDI usage in JavaScript.

Getting Access to the MIDI System

This example shows how to request access to the MIDI system.

var midi = null;  // global MIDIAccess object

function onMIDISuccess( midiAccess ) {
  console.log( "MIDI ready!" );
  midi = midiAccess;  // store in the global (in real usage, would probably keep in an object instance)
}

function onMIDIFailure(msg) {
  console.log( "Failed to get MIDI access - " + msg );
}

navigator.requestMIDIAccess().then( onMIDISuccess, onMIDIFailure );

Requesting Access to the MIDI System with System Exclusive Support

This example shows how to request access to the MIDI system, including the ability to send and receive system exclusive messages.

var midi = null;  // global MIDIAccess object

function onMIDISuccess( midiAccess ) {
  console.log( "MIDI ready!" );
  midi = midiAccess;  // store in the global (in real usage, would probably keep in an object instance)
}

function onMIDIFailure(msg) {
  console.log( "Failed to get MIDI access - " + msg );
}

navigator.requestMIDIAccess( { sysexEnabled: true } ).then( onMIDISuccess, onMIDIFailure );

Listing Inputs and Outputs

This example gets the list of the input and output ports and prints their information to the console log.

function listInputsAndOutputs( midiAccess ) {
  var inputs = midiAccess.getInputs();
  var outputs = midiAccess.getOutputs();
  var i;

  for (i=0; i<inputs.length; i++) {
    console.log( "Input port #" + i + 
      ": type:'" + inputs[i].type +
      "' id:'" + inputs[i].id +
      "' manufacturer:'" + inputs[i].manufacturer +
      "' name:'" + inputs[i].name +
      "' version:'" + inputs[i].version + "'" );
  }

  for (i=0; i<outputs.length; i++) {
    console.log( "Output port #" + i + 
      ": type:'" + outputs[i].type +
      "' id:'" + outputs[i].id +
      "' manufacturer:'" + outputs[i].manufacturer +
      "' name:'" + outputs[i].name +
      "' version:'" + outputs[i].version + "'" );
  }
}

Handling MIDI Input

This example prints incoming MIDI messages on a supplied input port to the console log.

function onMIDIMessage( event ) {
  var str = "MIDI message received at timestamp " + event.timestamp + "[" + event.data.length + " bytes]: ";
  for (var i=0; i<event.data.length; i++) {
    str += "0x" + event.data[i].toString(16) + " ";
  }
  console.log( str );
}

function startLoggingMIDIInput( midiAccess, indexOfPort ) {
  var input = midiAccess.getInput( indexOfPort );
  input.onmidimessage = onMIDIMessage;
}

Sending MIDI Messages to an Output Device

This example sends a middle C note on message immediately on MIDI channel 1 (MIDI channels are 0-indexed, but generally referred to as channels 1-16), and queues a corresponding note off message for 1 second later.

function sendMiddleC( midiAccess, indexOfPort ) {
  var noteOnMessage = [0x90, 60, 0x7f];    // note on, middle C, full velocity
  var output = midiAccess.getOutput( indexOfPort );
  output.send( noteOnMessage );  //omitting the timestamp means send immediately.
  output.send( [0x80, 60, 0x40], window.performance.now() + 1000.0 ); // Inlined array creation- note off, middle C,  
                                                                      // release velocity = 64, timestamp = now + 1000ms.
}

A Simple Loopback

This example loops all input messages on the first input port to the first output port - including system exclusive messages.

var midi = null;  // global MIDIAccess object
var output = null;

function echoMIDIMessage( event ) {
  if (output) {
    output.send( event.data, event.timestamp );
  }
}

function onMIDISuccess( midiAccess ) {
  console.log( "MIDI ready!" );
  try { 
    var input = midiAccess.getInput( 0 );
    input.onmidimessage = echoMIDIMessage;
    output = midiAccess.getOutput( 0 );
  }
  catch (e) {
    console.error("Exception! Couldn't get i/o ports." + e );
  }
}

function onMIDIFailure(msg) {
  console.log( "Failed to get MIDI access - " + msg );
}

navigator.requestMIDIAccess().then( onMIDISuccess, onMIDIFailure );

Security and Privacy Considerations of MIDI

There are two primary security and privacy concerns with adding the Web MIDI API to the web platform:

Allowing the enumeration of the user's MIDI interfaces is a potential target for fingerprinting (that is, uniquely identifying a user by the specific MIDI interfaces they have connected). Note that in this context, what can be enumerated is the MIDI interfaces - not, for example, an individual sampler or synthesizer plugged into a MIDI interface, as these would not be enumerated, unless those devices are connected to the host computer with USB (USB-MIDI devices typically have their own MIDI interface, and would be enumerated). The interfaces that could be fingerprinted are equivalent to MIDI "ports", and for each device the API will expose the name of the device, manufacturer, and opaque identifier of the MIDI interface (but not any attached devices).
Few systems will have significant numbers of MIDI devices attached; those systems that do will typically use hardware MIDI interfaces, not fanning out a dozen USB-MIDI connections through USB hubs. In this case, of course, enumerating the MIDI “devices” will only see the hardware MIDI interface(s), not the synthesizers, samplers, etc. plugged into it on the other side. Given the few number of devices plugged in, the amount of information exposed here is fairly symmetric with the fingerprinting concern exposed by other APIs such as the Gamepad API. The vast majority of systems have relatively few MIDI interfaces attached.
Separate from the fingerprinting concerns of identifying the available ports are concerns around sending and receiving MIDI messages. Those issues are explored in more depth below.

In brief, the general categories of things you can do with MIDI ports are:

Sending short messages (all messages except SysEx)
Receiving short messages (all messages except SysEx)
Sending SysEx messages. SysEx messages include both commonly recognized MIDI Time Code and MIDI Sample Dump Standard, as well as device-specific messages (like “patch control data for a Roland Jupiter-80 synthesizer”) that do not apply to other devices.
Receiving SysEx messages.

The impact of each of these is:

Sending short messages: sending note-on/note-off/controller messages would let you cause sounds to be played by attached devices, including (on Mac and Windows) any default virtual synthesizers. This by itself does not cause any concerning exposure - you can already make sounds without interaction, through
Receiving short messages: receiving note-on/note-off/controller messages would not cause any information exposure or security issues, as there is no identifying data being received, just a stream of controller messages - all of which must be initiated by the user on that MIDI device (except clock-type messages). This is very analogous to receiving keyboard or mouse events.
Sending and Receiving SysEx. This is the biggest concern, because it would be possible to write code that looked for system-specific responses to sysex messages, which could identify the hardware available, and then use it to download data - e.g. samples stored in a sampler - or replace that data (erasing sample data or patches in the device), although both these scenarios would have to be coded for a particular device. It is also possible that some samplers might enable a system exclusive message to start recording a sample - so if the sampler happened to have a dedicated microphone attached (uncommon in practice, but possible), it would be possible to write code specific to a particular device that could record a short sample of sound and then upload it to the network without further user intervention. (You could not stream audio from the device, and most samplers have fairly limited memory, and MIDI Sample Dump sysex is a slow way to transfer data - it has to transcode into 7-bit - so it’s unlikely you could listen in for long periods.) More explicit fingerprinting is a concern, as the patch information/stored samples/user configuration could uniquely identify the system (although again, this requires much device-specific code; there is not standardized “grab all patches and hash it” capability.) This does suggest that system exclusive messages are in a security category of their own.

It's also useful to examine what scenarios are enabled by MIDI, mapped against these features:

Receiving short messages. This is the most attractive scenario for Web MIDI, as it enables getting input from keyboards, drum pads, guitars, wind controllers, DJ/controllerist controllers, and more, and use those messages as input to control instruments and features in the Web Audio API as well as other control scenarios (MIDI is the protocol of choice for the multi-billion-dollar music production industry for getting physical controllers like knobs and buttons attached to your computer, both in pro/prosumer audio and media applications as well as consumer applications like Garageband.)
Sending short messages - it’s tempting to say sending is significantly less interesting, as the scenario of attached output devices like hardware synthesizers is less common in today's market. The major exception to this is that many of the MIDI controllers have external host control of their indicator lights, and this makes them dramatically more useful. For example, the very popular Novation Launchpad controller uses MIDI note on/off messages sent to it to turn on/off and change colors of the buttons. The same is true of nearly all DJ controllers.
Sending and receiving SysEx - obviously, for more advanced communication with high-end hardware devices, SysEx is required. Unfortunately, some common MIDI commands are also sent as system exclusive messages (MIDI Machine Control, for example - generic start/stop/rew/ffw commands) - and many devices use system exclusive to program patches, send advanced controller messages, download firmware, etc., which are much-demanded scenarios for Web MIDI. Some devices use sysex as a direct control protocol, as they can pack more data into a single “message”, and most devices use SysEx as way to save and restore patches and configuration information on less-expensive computer storage. Several of the major music hardware producers have expressed strong interest in using Web MIDI to provide web-based configuration and programming interfaces to their hardware. In short, disabling sysex altogether does not only disable high-end scenarios.

In short: the additional fingerprinting exposure of enumerating MIDI devices is directly analogous to the Gamepad API’s additional fingerprinting exposure through gamepad enumeration; typical users will only have at most a few devices connected, their configuration may change, and the information exposed is about the interface itself (i.e., no user-configured data).

The additional security concern for receiving short messages is also small - it’s analogous to listening to keyboard, mouse, mobile/laptop accelerometer, touch input or gamepad events; there is no additional information exposed, and all messages other than clock signals must be initiated by the user.

The additional concerns about sending short messages are analogous to any audio output - you cannot overwrite user information or expose use information, but you can make sounds happen, change patches, or (in rare configurations) toggle lights - but non-destructively, and not persistently.

System Exclusive, on the other hand, has a much less bounded potential, and it seems that distinguishing requests for SysEx separately in the API is a good idea, in order to more carefully provide user security hooks. The suggested security model explicitly allows user agents to require the user's approval before giving access to MIDI devices, although it is not currently required to prompt the user for this approval - but it also detailed that system exclusive support must be requested as part of that request.

Introduction

Terminology