Network MIDI 2.0 (UDP) Overview

Florian Bomers

Benefits of Network MIDI 2.0

Ethernet and wireless LAN are suitable transports for MIDI. They complement, and can sometimes replace, established MIDI transports like 5-Pin DIN and USB MIDI.

Highlights:

Long distance
- Ethernet cables can transmit data up to 100 meters (330ft) without any signal loss or degradation.
- Wireless can reach up to 45m (150ft) with direct line of sight (actual distance depends on a number of factors)
Low latency
- Typical latency on Ethernet is under 1ms. Wireless LAN latency depends on connection quality and technology, but typically under 5ms.
High bandwidth
- 100MBit/s or more on Ethernet, 1MBit/s or more on wireless LAN
- One cable/wireless link is enough for many logical connections
Ground isolation
- On Ethernet, connections are electrically isolated, reducing the chances of electrical grounding noise issues.
Auto-Discovery
- Can select devices to connect by name
Off-the-shelf parts and infrastructure
- Standard cables (Cat5, Cat6, etc.), routers, switches, and components are readily available and cost effective
- Many transports for audio already use Ethernet or IP-based protocols. Some of those are open standards (i.e. AES67) and some are proprietary. Being able to run MIDI 2.0 as a control protocol over the same links that run audio can greatly expand the use of MIDI 2.0.
Wireless MIDI 2.0 using Wireless LAN
- The same protocol can be used on wired connections via Ethernet, and wireless connections on wireless LAN, also in mixed environments.
Logical connection setup (Session Management)
- The user has full control over which device is able to send/receive MIDI with which other device (or application)
- Connections can be changed without having to move physical cables.
- Many MIDI streams (sessions) can be configured on the same cable
- Simple security mechanisms available in Network MIDI 2.0 help prevent unauthorized access
Peer to peer connection is possible without the need to route data through a computer.
Software implementations do not require OS support

Example of a networked MIDI studio:

Who can take Advantage of Network MIDI 2.0?

Every MIDI user can benefit of Network MIDI 2.0: it provides a bridge between MIDI 1.0 and MIDI 2.0 devices.

Although Network MIDI 2.0 is particularly well suited as a MIDI transport, other transports like USB-MIDI 2.0, and the good old MIDI 5-pin DIN, have their own merits. Therefore, Network MIDI 2.0 is just one more transport for MIDI.

Who’s In? Network MIDI 2.0 at NAMM 2025

The first products which use this specification are starting to be released and will be featured at The MIDI Association booth 10302 at the front of Hall A at the 2025 NAMM show.

Examples for announced or available products with Network MIDI 2.0:

MIDI Workbench
https://github.com/midi2-dev/MIDI2.0Workbench
AmeNote Mitosys
https://amenote.com/?page_id=251
BomeBox
https://www.bome.com/products/bomebox
KissBox
https://kiss-box.com/
Microsoft Windows
https://devblogs.microsoft.com/windows-music-dev/category/midi/
MusiKraken
https://www.musikraken.com

The MIDI Association will also host a presentation at the NAMM Show about Network MIDI 2.0, Thursday, January 23, 2025 1:00 PM.

For more info, see here: https://midi.org/event-calendar/network-midi-2-0-udp-transport-specification

Specification Details for Developers

Which Devices and Applications can use Network MIDI 2.0?

To add Network MIDI 2.0 in support to your device, the requirements are reasonably simple. First, there are the physical components (connector, transformer, …). Secondly, the software implementation needs to provide IP and UDP functionality, plus the implementation of the Network MIDI 2.0 protocol itself. The standard is designed with the goal that even systems with little memory will be able to implement the minimum required set of Network MIDI 2.0 features.

Software applications can implement the Network MIDI 2.0 standard using OS provided APIs for IP and UDP functionality. However, we expect availability of general-purpose Network MIDI 2.0 connector applications, and OS components and APIs, so that most applications do not need to implement the Network MIDI 2.0 standard on their own. Remote MIDI devices may be used the same as locally connected MIDI devices.

Version 1.0: Simplicity

The first version of Network MIDI 2.0 was developed with the goal of providing an easy to use and easy to implement solution. Only essential features are specified. The specification is limited to Local Area Networks using wired Ethernet and wireless LAN. Data transfer uses UDP as the underlying protocol.

However, the standard is extensible, so we may see updated specification versions with additional, backwards compatible, functionality.

Three Sections

The standard is divided into three sections:

Section 1: Discovery

Who’s out there?

Section 2: Session

Connection setup and tear down

Section 3: Data I/O

Send and receive UMP

Let’s start with a description of the first section.

Section 1: Discovery

The discovery allows a device (or application) to find other Network MIDI 2.0 devices (hardware or software applications) which are reachable via the network.

User Friendly

Discovery allows users to select MIDI device(s) to connect to by name. Imagine a keyboard with a display, where you have a list of synthesizers in your studio, and you just select the one you want to play… done!

Using Established Standards

Network MIDI 2.0 discovery uses the established standard mDNS with DNS-SD. This standard is also known as “ZeroConf networking” and as “Apple Bonjour”. This allows devices to advertise their MIDI 2.0 services using the publicly registered service type: “midi2”. This discovery allows mDNS/DNS-SD devices to get the following information about a Network MIDI 2.0 device:

IP Address
UDP Port
UMP Endpoint Name*
Product Instance Id*

*These properties are defined by MIDI specifications.

Operating System Support

Common operating systems already provide mDNS services for use by applications, so it is simple to add Network MIDI 2.0 Discovery to your implementation.

Optional

Network MIDI 2.0 Discovery is optional. But we highly recommend implementing it in your device. Otherwise, your users won’t be able to select your device by name!

Some special devices may not need Discovery. For example, in some systems a device will need to be hard wired somehow (using a fixed IP address), where such auto-discovery wouldn’t make much sense.

Section 2: Session

The Session section is all about (logical) connections of Network MIDI 2.0 devices. The term Session is used here, because the word “connection” could mean many other things, too.

The Session functionality is required for all Network MIDI 2.0 devices, because plugging an Ethernet cable into a network does not tell the device with which other MIDI device you want to be “MIDI connected”.

Client and Host

In Network MIDI 2.0 terminology, a Client starts a Session with a Host. A typical scenario is that the Hosts advertise their Network MIDI 2.0 services via Discovery, and the Client selects a Host, then starts the session with it. Of course, a single device can assume both Client and Host roles for different Sessions. In fact, we expect that most devices and applications will be both Host and Client (i.e. they’re discoverable, and they can initiate a Session).

Session Commands

The Network MIDI 2.0 Session specifies different Session Commands for starting a Session (Client), accepting a Session (Host), and terminating a running Session (both Client and Host).

Under the hood, the Session Commands are plain UDP messages with a short, simple header which specifies which MIDI-specific Session Command is being sent.

Authorization

The two-step Session setup allows devices (in Host role) to ask the user to acknowledge an incoming Session request. This is useful for devices with public access, or where you don’t want random people to play your synth via the network.

Authentication

Additionally, the Session specification also provides mechanisms to secure a Session with a password or PIN for a successful Session initiation, or to provide a valid user+password combination.

Note that the Authentication mechanisms currently provided in Network MIDI 2.0 only provide simple security and do not use any encryption. But they are simple to implement, and do provide a minimum level of security.

These Authentication mechanisms are optional. But keep in mind that a Host may require Authentication: in that case, your Client will only be able to connect if it can provide the Host with a matching password or username + password. In general, though, we recommend that a Host can be configured to require Authentication or not.

Multi-Session

The Network MIDI 2.0 standard allows very flexible session configurations. Examples:

One Client can connect to multiple Hosts
One Host can accept Sessions from multiple Clients
A device can use multiple Client instances for multiple Sessions to the same Host
A device can also have multiple Hosts, e.g. for separate logical units (although, because we’re sending UMP, separate Groups can be used for that).

Handling Command Packet Loss

Because UDP does not guarantee packet delivery, the Session protocol is designed to gracefully handle a lost Session Command. Most Session Commands (like the Invitation Command to request the start a Session) are repeated until a reply is received. During that time, the Command is pending, and can be terminated by the user, or if a time-out occurs (depending on the implementation).

To further check that a remote Host is still alive, the Ping Command can be used. The remote Host will reply with the Ping Reply Command if it is still powered on and connected to the network.

Section 3: Data Transmission

The third section of the Network MIDI 2.0 specification is all about sending and receiving MIDI messages in the Universal MIDI Packet data format (UMP). As you know, UMP can contain messages in MIDI 1.0 protocol and in MIDI 2.0 protocol.

Session Established: Can Send and Receive UMP

Once the Session is established, both Host and Client can send and receive UMP, where the full UMP feature set is available. The Network MIDI 2.0 layer is agnostic to the UMP contents: any UMP packet will be transmitted. The Network MIDI 2.0 layer never creates or consumes UMP messages, and there is no need for the (deep) inspection of the UMP data.

Multiple Commands per UDP

For sending UMP, the UMP Data Command is used. Because it uses the same header as Session Commands, you can mix and match Session Commands with UMP Data Commands in one UDP packet for efficient transmission. The flexible Command allows multiple UMPs in one UMP Data Command, and multiple UMP Data Commands per UDP packet.

Data Integrity: Sequence Number

Every UMP Data command has a sequence number. It allows receivers to detect:

out-of order packets
missing packets
duplicate packets

Data Integrity: FEC

Forward Error Correction (FEC) is a simple mechanism to recover from occasional loss of a packet. Remember, UDP does not guarantee delivery of packets…

The idea of FEC is that when a sender sends UMP data in a UDP packet, it routinely includes the two most recent UMP Data Commands in the same UDP packet. So from the point of view of the receiver, if one UDP packet gets lost, the receiver will get the missing UMP with the next UDP packet. Receivers, on the other hand, always discard UMP Data Commands with a sequence number they have already processed. Because the FEC Data Commands have previous sequence numbers, receivers will usually ignore the additional FEC Data Commands.

Because FEC has very low requirements for both senders and receivers, it is highly recommended that all devices implement FEC.

FEC can also be combined with the following mechanism for even higher data integrity.

Data Integrity: Retransmit

If the local device discovers a missing packet (and FEC does not fix it), a Retransmit can be requested from the remote device. If the remote device keeps a Retransmit buﬀer, it can resend the missing packet. Otherwise, it notifies the local device via a Retransmit Error Command that the buffer does not contain the missing packet.

Retransmit functionality is optional for both sending and receiving side. If a device does not keep a retransmit buffer at all, it will respond with a NAK Command when it receives a Retransmit request. That’ll let the other device know that there is no point in further trying Retransmit.

Ethernet Packet Format for Network MIDI 2.0

Possible Future Plans

The MIDI Association has tried to keep the standard simple. To better clarify the scope of the current version, here are a few features that are not in the initial version but might be added in future expansions of the specification.

Encryption

Network MIDI 2.0 does not provide any encryption of the UMP data (or of the Session Commands). If encryption is required, it can be configured on a lower layer, for example with a VPN or an encrypted tunnel. This is currently outside the scope of the Network MIDI 2.0 standard.

Clock or Synchronization

In the first version, the Network MIDI 2.0 standard does not define any mechanism for time synchronization. Clock and synchronization mechanisms are available on the UMP layer, e.g. JR Timestamps or MIDI 1.0 clock.

Remote Session Management

Version 1.0 of the Network MIDI 1.0 standard defines Session management between pairs of devices (“device A with device B”). Remote Session management would allow device A to tell device B to initiate a Session with device C. Such functionality would be useful for central studio and stage management.

There is no defined method to do this at this time, but the MIDI Association sees a lot of value in remote Session management and may add it to the standard in a future revision.

Interested in adding Network MIDI 2.0 to your products

We’d love to hear from you if you’re interested in adding Network MIDI 2.0 to your product, or if you have any comments!

The MIDI Association is working on a series of articles for assisting you with the implementation of the Network MIDI 2.0 standard into your product. You can sign up to receive notifications here:

https://midi.org/individual-membership-app