fbpx
Skip to main content
MIDI Network Logo

Network MIDI 2.0 (UDP) Overview

Written by Florian Bomers on . Posted in Developers, MIDI 1.0, MIDI 2.0, MIDI 2.0 Resources for Developers, MIDI Association Event List, MIDI News, NAMM.

User Datagram Protocol for Universal MIDI Packets (aka Network MIDI 2.0) defines a standard way to connect MIDI devices (MIDI 1.0 and MIDI 2.0 protocol) via Ethernet and wireless LAN. The initial version was ratified by the MIDI Association and AMEI in November 2024.

The specification can be downloaded here:

https://midi.org/network-midi-2-0

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:

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 buffer, 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

MIDI-CI Responder

MIDI-CI: Handling Multiple Initiators and Responders

Written by Andrew Mee on . Posted in Developers, MIDI 2.0, MIDI 2.0 Resources for Developers.

Developer Design Options for Devices based on MIDI-CI v1.2

by Andrew Mee and Mike Kent

MIDI-CI defines how a device can use a bidirectional connection to discover details of another device. In some cases a device might be connected to more than 1 other device which also uses MIDI-CI. 

This article discusses device design strategies for handling MIDI-CI functions when the current connections are more than one to one. For this purpose we present two terms which are not defined by MIDI-CI but used only to explain design strategies in this article.

  • Session: A binding between 2 devices created by ongoing communication of MIDI-CI Transactions. Generally established while using a Profile, a PE Resource, or a Process Inquiry.
  • MIDI-CI Instance: Inside a MIDI device, a set of information stored about another connected MIDI-CI device, with the MUID of the connected device as the core property.

A Session often requires a MIDI-CI Instance in the Initiator and sometimes in the Responder.

MIDI-CI defines that a Transaction is an inquiry sent by one MIDI Device and a reply returned by a second MIDI Device. Single Transactions do not establish any kind of Session. Therefore, and in most cases, the following Transactions do not require a MIDI-CI Instance in a device.

  • Discovery
  • Profile Inquiry
  • Inquiry: Property Exchange Capability
  • Inquiry: Process Inquiry Capability

Some MIDI-CI mechanisms rely on an ongoing set of Transactions. These mechanisms probably require a device to consider those mechanisms as establishing a kind of Session between two devices. One or both devices might require an internal MIDI-CI Instance. Such mechanisms are:

  • When 2 Devices agree to use Process Inquiry, the Initiator usually creates a MIDI-CI Instance. The Responder may not need a MIDI-CI Instance.
  • When two Devices agree to use a Profile, the Initiator usually creates a MIDI-CI Instance. The Responder may not need a MIDI-CI Instance.
  • When 2 Devices agree to use a Property Exchange Resource, the Initiator usually creates a MIDI-CI Instance. The Responder usually only needs a MIDI-CI Instance if it agrees to serve subscriptions.

Do Not Create a MIDI-CI Instance Unless Necessary

Note: Devices should send the associated reply to these inquiries, even if the Device cannot create a new MIDI-CI Instance:

  • Discovery -> Reply to Discovery
  • Profile Inquiry -> Reply to Profile Inquiry
  • Inquiry: Property Exchange Capabilities -> Reply to Property Exchange Capabilities
  • Inquiry: Process Inquiry Capabilities -> Reply to Process Inquiry Capabilities
  • Inability to create a new MIDI-CI Instance should not cause sending a NAK.  (There may be other reasons to reply with a NAK.)

Sending a reply to these inquiries only requires the Responder to store information about the inquiry, including the MUID address of the Initiator, until the Responder has sent a reply.

Example Implementation Scenarios for Devices with Limited Resources

Some devices have limitations of memory and processing power. Typically, hardware devices have more limitations than software applications running on a computer. Following are 2 examples of potential issues, each with several proposed solutions.
Some of the solutions provided are for normal MIDI-CI mechanisms, but some are provided to deal with error cases such as a device which becomes disconnected without sending an Invalidate MUID message.

Example 1: Responder Device Restricted to Supporting Single MUID

In this example, a limited hardware device which acts only as a Responder is connected to a computer with the potential for multiple MIDI-CI Initiators. The Responder only has enough memory to store a single MIDI-CI Instance.

There are potential issues which could occur:

  • If the Responder creates a MIDI-CI Instance for the first Initiator which requests a connection, that could “lock” the Responder against other MIDI-CI Instances. The Responder might NAK other Initiators. The Responder may not be able to determine that a different Initiator is preferred.
  • If an Initiator “goes away” without sending invalidate MUID, Responder is unable to see that Initiator no longer exists. i.e. no clean-up
  • Responder has limited methods to verify Initiator still exists.

Responder Solution 1: Device Does Not Create a MIDI-CI Instance to Store Initiator MUID/Info

A simple MIDI-CI Device (with restricted memory), acting as a Responder, probably does not need to store the Initiator MUID and associated information. Instead, Responder might:

  • Respond to request from the Initiator using the Source MUID from the request as the Destination MUID in the reply. Then forget the MUID of Initiator.
  • Only Send out Notifications using the Broadcast MUID. e.g. Profile Enable Message.

Responders using this method do not need to track active status of Initiators. No MIDI-CI Instance has been created so no “clean-up” needed.

Note: This solution is not applicable in a few cases (because in these cases the Responder probably needs to create a MIDI-CI Instance):

  • The Responder wants to accept Property Exchange Subscriptions requests.
  • An active Profile requires the Responder to send notifications to an Initiator using a non-Broadcast address.
  • The Responder is expected to make a Profile Details Inquiry of the Initiator more than once after a Profile is enabled.
  • More than 512 bytes of Sysex data is needed to be sent on any given MIDI-CI message.

However, many Responders will work well without any of the mechanisms listed above.

Responder Solution 2: Device Only Stores Minimal Initiator Information When Absolutely Needed

Responder should only store the data which is absolutely needed for each MIDI-CI Instance.
There is a lot of data provided in MIDI-CI messages, much can be “thrown away”. Some examples of data which might not need to be stored:

  • Manufacturer, Family, Model Id’s, and Version are often not needed. 
  • Devices that are only working with Profiles do not need to store PE data.
  • Max Sysex only important if you are going to use messages greater than 512 bytes

A clean-up mechanism to remove inactive MIDI-CI Instances should be considered when this solution is used.

Example Device: The MIDI Association developed a prototype to test and demonstrate Property Exchange. The device has a total memory of only 96Kb.
The device only creates a MIDI-CI Instance when a Subscription is requested. When a change occurs, the device looks through the list of MIDI-CI Instances to find current subscription(s), and sends out the Property Exchange Subscription notification.
If Property Exchange Subscription Notification is sent and no Reply to Subscription Message is received, a clean-up process is initiated for that MIDI-CI Instance.

This method keeps memory use to a minimum. This prototype can manage 25 unique Subscriptions in fixed memory, using less than 256 bytes.

Responder Methods of “Clean-up”:

  • Do Not Create MIDI-CI Instance – no need for clean-up (suitable for many devices but not in all situations, see Responder Solution 1)
  • Use MIDI-CI Messages sent directly to Initiator (not Broadcast) and check for Reply. If there is no reply then it can be considered inactive and removed from memory.
  • Resend Discovery. If an existing Initiator does not respond it can be considered inactive and removed from memory.
  • Receive Invalidate MUID message containing Initiator MUID.

Example 2: Initiator Device Discovers many Responders available for Communication

In this example, a limited hardware device which acts as an Initiator is connected to a computer with the potential for multiple MIDI-CI Responders. The Initiator has limited memory for MIDI-CI Instances.

There are potential issues which could occur after the Discovery Transaction:

  • The Responder may already have a MIDI-CI Instance for another Initiator (this may include inactive Initiators) and may NAK a new Session. 
  • The Initiator may have “choice paralysis”, as such the Initiator may have difficulty automatically deciding which Initiator  is best for the user.
  • The Initiator may be unaware if a Responder disappears in the future.

Solution: Initiator and Responder Implementations

Responder

  • Should support multiple Initiators. As Responder is on a computer, memory for multiple MIDI-CI Instances is not an issue.

Initiator

  • Offer a choice to the user for selecting which Responder to communicate with.
  • Use Clean-up methods (below) to remove inactive Responders.

Initiator Methods of “Clean-up”:

  • If the device receives an Invalidate MUID message containing Responder MUID, then remove the MIDI-CI Instance.
  • Resend Discovery to confirm that the Responder is still active. If a prior existing Responder no longer replies, the Responder can be considered inactive and removed from memory.
  • A Session and MIDI-CI Instance are usually needed to work with a Responder for one of 3 “P”s: Profile Configuration, Property Exchange, or Process Inquiry. Send a Profile Inquiry, PE Capabilities, or Process Inquiry Capabilities message periodically as a “Ping” to confirm that the Responder is still active.

Note: There is usually no need to create a MIDI-CI Instance for any device which does not support one of the 3 “P”s.

Windows MIDI 2.0 Detailed Architecture picture

Microsoft’s Major Moves To Make Making Music on Windows Easier

Written by The MIDI Association on . Posted in Developers, MIDI 2.0, MIDI 2.0 Resources for Developers, MIDI Association Event List, MIDI News, MIDI Product News, MIDI Software.

Pete Brown is both the MIDI Association Exec Board Chair and a Principal Software Engineer in the Windows Developer Platform team at Microsoft. He focuses on client-side dev on Windows, apps and technology for musicians, music app developers, and music hardware developers, and the Windows developer community. 

For musicians, there are two key enabling technologies for making music – MIDI and Audio.  Microsoft announced updates to both are coming soon to Windows. 

Microsoft announced updates to both MIDI and Audio at the Qualcomm Snapdragon Summit 2024.

What did we announce today for musicians and other audio professionals?

Musician Software coming to Arm64
Steinberg Cubase and Nuendo in preview this week
Cockos Reaper in preview today
Reason Studios Reason in preview in early 2025

Audio Hardware coming to Arm64
Vendor-specific USB Audio / ASIO driver preview from Focusrite early in 2025
Vendor-specific USB Audio / ASIO driver preview from Steinberg/Yamaha in 2025

In-Box Support coming to Arm64
ASIO and low-latency USB Audio Class 2 driver previews mid 2025, in-box in Windows when complete
MIDI 2.0 (Windows MIDI Services) previews in Windows Insider builds this November, in-box in retail Windows early next year.

From my own use and from working with others in the music industry, I know we need to have support for two major features on Windows for musicians to have a great experience:

Better APIs which support MIDI, including MIDI 2.0, with backwards compatibility with MIDI 1.0 APIs and devices. Our older MIDI stack hasn’t kept up with current needs, and needed replacing so that we can grow and innovate.

Full support for low-latency, high-channel-count audio, using standards already accepted by the industry

Pete Brown-Microsoft

Windows MIDI Services: The New Windows MIDI Stack

Windows MIDI 2.0 Detailed Architecture picture
Windows MIDI Services supports MIDI 1.0 as well as the MIDI 2.0 Universal MIDI Packet (UMP) standard. Together this provides compatibility with existing MIDI devices as well as the new MIDI 2.0 devices already in-market or coming soon (I have several MIDI 2.0 devices here in my studio).

MIDI CI, which bridges the gap between MIDI 1.0 and MIDI 2.0 UMP, is supported through normal SysEx support, and we recommend the use of open source cross-platform libraries which help with creating and parsing those messages. 

Pete Brown-Microsoft

Backwards compatibility with the WinMM MIDI 1.0 API

AMEI to Fund Open SourceMIDI 2.0 Driver for Windows

The Association of Musical Electronics Industries (AMEI), the organization that oversees the MIDI specification in Japan, committed to funding the development of an open-source USB MIDI 2.0 Host Driver for Windows Operating Systems under a memorandum of understanding between AMEI, AmeNote Inc, and Microsoft.

AMEI is underwriting the cost and has engaged AmeNote Inc. to develop the driver because of AmeNote’s extensive experience in MIDI 2.0 and USB development. In addition, concurrent to this, Microsoft has also agreed to start development of a Windows standard open-source MIDI 2.0 API.

The driver and API will be developed in accordance with Microsoft’s quality control standards, and will be managed as a permissively licensed (MIT license) Microsoft open-source project. As a result, anyone can participate in the development as an open-source contributor in the future, or use the code in their own devices or operating systems. Because of this open source arrangement, continuous and timely improvements and enhancements to the USB MIDI 2.0 Host driver and MIDI 2.0 API are expected.

Here is a list of the AMEI companies supporting this work.

l   AlphaTheta Corporation

l   INTERNET Co., Ltd.

l   Kawai Musical Instruments Manufacturing Co., Ltd.

l   CRYPTON FUTURE MEDIA, INC.

l   CRIMSON TECHNOLOGY, Inc.

l   KORG INC.

l   Educational Corporation Shobi Gakuen

l   SyncPower Corporation

l   ZOOM CORPORATION

l   -SUZUKI MUSICAL INST. MFG. CO.,LTD.

l   TEAC CORPORATION

l   Yamaha Corporation

l   Yamaha Music Entertainment Holdings, Inc.

l   Roland Corporation

l   Analog Devices, K.K.

For the full blog from Pete on the New Windows MIDI Stack, please click on the link below.

https://devblogs.microsoft.com/windows-music-dev/windows-midi-services-oct-2024-update/

Make Great Music with Windows on Arm

We’ve recently kicked off a project with Qualcomm and Yamaha to create a brand new USB Audio Class 2 Driver in Windows, with both WaveRT (our internal audio) and ASIO interfaces, following the latest standards for Windows driver development using the ACX framework.

The new driver will support the devices that our current USB Audio Class 2 driver supports, but will increase support for high-IO-count interfaces with an option for low-latency for musician scenarios.

It will have an ASIO interface so all the existing DAWs on Windows can use it, and it will support the interface being used by Windows and the DAW application at the same time, like a few ASIO drivers do today. And, of course, it will handle power management events on the new CPUs.

This driver will work with USB Audio Class 2 devices, so you can plug in your device, and get right to making music.

Finally, we’ll make the class driver source available to others on GitHub, just like we have with MIDI, so that any company creating their own USB Audio Class 2 drivers will be able to learn from how we handled events and also give us suggestions for how we could do better. It’s a two-way conversation.

Pete Brown-Microsoft

Announcing: Hardware-optimized USB Audio drivers on Arm64

Our new in-box driver needs to work well for all compliant USB Audio Class 2 devices. But some hardware developers are expert driver authors, and for years have known that if they write their own optimized drivers for their USB Audio Interfaces, even on other platforms with built-in drivers and low-latency APIs, they can achieve even better round-trip latency at the same levels of stability. Every millisecond counts!

Pete Brown-Microsoft

Focusrite – Native on Arm64

“Focusrite is targeting releasing native Arm64 drivers for all of its supported USB audio interface products in early 2025, bringing compatibility with all ASIO and non-ASIO applications running on the platform.”

Tim Carroll, CEO Focusrite Group

CEO Focusrite Group, President of The MIDI Association

Yamaha – Native on Arm64

Yamaha creates the Steinberg-branded USB audio interfaces, which are fantastic performers on Windows and loved by their customers. In addition to working on the in-box class driver for Arm64, they are going to release optimized device-family versions of their audio interface drivers for Windows on Arm, giving users of their devices the best of both worlds.
We’re excited to see these drivers coming out for Arm64 in 2025!

Pete Brown- Microsoft

Announcing: New Musician-focused apps coming to Arm64

With the new MIDI stack and in-box ASIO, these three killer DAW apps, and two families of audio interfaces with optimized drivers for Arm64, we’re set up to help make the experience of creating music amazing on Windows. I am beyond excited for so many of these efforts to come together at this point in time. A huge thanks to all our hardware and software partners who have stepped up to help musicians and other audio creators on Windows.

Pete Brown-Microsoft

Cubase x Snapdragon: Redefining mobile music production

For the full blog from Pete on Make Great Music with Windows on Arm, please click on the link below.

https://devblogs.microsoft.com/windows-music-dev/making-music-on-windows/

Picture of Digishow Store Display

Digishow-Jam With Everything

Written by The MIDI Association on . Posted in Developers, DYI/Arduino/Maker/Robots, MIDI News, MIDI Product News, MIDI Software, Music China.

At the MIDI Forum, there were a number of technology presentations and one of the most fascinating was from Robin Zhang about the open source software he developed called Digishow.

Robin runs a creators’ collective in a beautiful old building that used to be the home of the Lester School and Technical Institute. They get diverse people from different backgrounds (musicians, lighting, artists, designers) to work together and create unique pieces of art using Digishow.

DigiShow is a lightweight control software designed for live performances and immersive show spaces with music, lights, displays, robots and interactive installations. It serves as an easy-to-use console for signal controlling, also enables signal mapping between MIDI, DMX, OSC, ArtNet, Modbus, Arduino, Philips Hue and more digital interfaces.

With using DigiShow LINK app, there are some scenarios assumed:

Producers: For live music or theatre performances, DJ or producers can arrange show lighting cues and stage automations on MIDI tracks alongside the music tracks in Ableton Live or other DAW. At the show, press the button on the Launchpad, the music loop and lighting effects will be instantly played in sync.

Ableton Live with tracks programmed for Digishow
Picture of magnetic and MIDI demo with lightshow

Performers: When playing MIDI instruments like drums or keyboards, DigiShow can trigger dynamic lighting changes and even robotic movements by MIDI notes following the beat or the music. Sensors can also be added to acoustic or DIY instruments to automatically generate MIDI notes.

Artists and Designer: For building interactive art installations, the creators often need to make software that works with the hardware. DigiShow provides OSC, ArtNet, WebSocket pipes for inter-application communication. Designers can create their interactive content in some creative software like TouchDesigner, Unity 3D, P5.js and access the hardware easily through DigiShow. Developers can also program using Python or JavaScript to connect DigiShow and extend interaction logic.

Storefront Display programmed by Digishow and simulated in Touch Designer

Makers and Hobbyists: DigiShow is for all show makers as well as hobbyists with little professional skills. Make digital shows for your own party time, or just make your house into a mini ‘disneyland’.