It's been a few months since I started working hard on implementing USB MIDI 2.0 on embedded systems. My starting points were Andrew Mee's AM_MIDI2.0Lib (MIDI 2.0 protocol), AmeNote's tusb_ump, and Mike Kent's ProtoZOA (embedded and USB), along with the official specs. My interest in this topic came from work I've been doing for a few years on MIDI transports for ESP32 (<a href=" removed link " target="_blank" rel="noopener noreferrer">ESP32_Host_MIDI). Along that path, I've been learning a bit about embedded architecture and the transport layer, especially USB.

It took many weeks of testing against Linux and Windows hosts, reading through M2-104-UM and the USB MIDI 2.0 Class Definition paragraph by paragraph. Last month I reached a stable version using TinyUSB, both Device and Host modes, validated first on RP2040 and then on Adafruit Feather RP2040 Host (Pico SDK, CMake). After testing across several devices, I opened the upstream PR: <a href=" removed link " target="_blank" rel="noopener noreferrer"> removed link .

Since then, I've been running a local branch based on the PR to keep the work moving. And that's the reason for this post: to see if others are on the same path and find allies here in the forum to push embedded MIDI 2.0 forward. So far, on my bench, I've enumerated on RP2040, RP2350, ESP32, Nordic nRF52840, and SAMD21. All of them enumerated cleanly on both Windows MIDI Services and Linux.

One angle in particular has been getting special attention: Teensy, Daisy Seed, and ESP32-P4. These are hacker-friendly boards with real audio processing capability. The experiments on these three are well under way, and this axis, where MIDI 2.0 meets real embedded audio, is where I'm going deeper.

It's been a really good experience. I'm excited about where this is going, and it would be great to find others walking a similar path.

I had a catch-up with Athan Billias recently, regarding WebMIDI.
It started out as a chat about my a new App I'm developing, called MIDIWeb ( removed link ) - a browser focused on making WebMIDI practical on iOS.
It ended up with a suggestion of:

'You should start a community-driven site for cool WebMIDI sites to help spread the word and gain some momentum in preparation of WebMIDI 2.0 support... and maybe see if there's appetite for a WebMIDI working group..."

So this post is an attempt to get a little momentum going in the open:

1) Is there interest here in forming a lightweight “WebMIDI Working Group” (or special interest group) focused on:

• increasing awareness + practical adoption of WebMIDI
• sharing best practices / dev pitfalls / security + permissions gotchas
• helping keep energy behind "WebMIDI + MIDI 2.0" discussions (and feeding that back into the right standards channels)

2) Do initiatives like this already exist that I’m missing?

• I’m aware the old W3C Web MIDI Community Group is closed, and there are broader audio groups — but I’m specifically wondering if there’s an active, practical community hub today for WebMIDI work?

As a first step, I’ve put together a community-driven directory of WebMIDI sites/tools, so people can quickly see what’s possible and add their favourites:

   MIDIWeb Hub: <a href=" removed link "> removed link

This directory is now also the home page of MIDIWeb, but the directory itself is meant to be useful regardless of what browser/app you use. I’d love for it to become a “living list” that the community actually maintains.

If a WebMIDI Working Group does sound worthwhile, a few possible starter outputs could be:

• a curated "Top WebMIDI examples" shortlist (education, performance, tools, games, utilities) - perhaps piggybacking on MIDIWeb-Hub?
• a simple "Getting started" + "Known issues across platforms", "WebMIDI Learning resources"  doc
• a wish-list / priority list for “WebMIDI + MIDI 2.0” features that developers would actually use
• coordination with any existing MIDI 2.0 / education efforts (so WebMIDI doesn’t become an island)

If you’re interested, reply with:

• "Yes, I’d join" + (and what you’d want it to achieve)
• any existing groups/threads/people I should connect with?
• any WebMIDI sites/tools you think absolutely should be in the directory?

The goal here is just to get the ball rolling and see if there’s real signal before we over-organise anything! 🙂 

Cheers,
Ant, 5of12
JOIN THE MIDIWEB TESTFLIGHT BETA: removed link

This setup is strictly experimental — not a public release. It focuses on measuring event latency, jitter, and buffer performance during extended sessions.

Test Setup

• Android Versions: 7.0 → 14

• Devices: 3–8 GB RAM, typical mid-range models

• MIDI Interface: USB OTG

• Browser: Chrome (stable)

• Load Scenarios: idle vs moderate background processes

Testing Methodology

• External metronome at 120 BPM as timing reference

• Capture timestamps via JavaScript callbacks

• Record 500–1000 event cycles per test

• Analyze median latency and variance

Observations

Baseline / Idle

• Average latency: 9–13 ms

• Jitter range: ±3–5 ms

• UI performance stable at 60 FPS

Under Background Load

• Latency spikes: 17–22 ms on Android 7–9

• Minor jitter during USB reauthorization

• Drift visible after idle periods over 15–20 minutes

Android 11+ Improvements

• Event buffer consistency significantly better

• Fewer spikes and lower overall drift

Additional Insights

• Older Android kernels seem sensitive to USB polling intervals

• Chrome stable handles event queues more predictably than some Chromium forks

• Resetting USB authorization occasionally improves long-session stability

Open Questions / Discussion Points

• Any experience profiling Web MIDI timing on Android 7 or 8 with high-resolution instruments?

• Recommended buffering strategies to keep drift below 10 ms for long sessions?

• Known OTG limitations for mid-range devices under sustained MIDI playback?

• Best practices for maintaining stable Web MIDI sessions over 30–60 minutes on mobile?

• Benchmark comparisons from real-world 188CM setups outside controlled lab conditions?

Would love to hear insights or shared experiences from developers working with Web MIDI on Android — especially if you’ve tested long-duration sessions using 188CM environments.

The tests were conducted using an internal benchmark harness (code name: <a href=" removed link " target="_blank" rel="noopener">VN68 Lab, 2026 iteration), designed strictly for event timing diagnostics and routing simulation.

This is not a public software release — it is simply a controlled test environment used to observe real-time MIDI behavior under varying system conditions.

Environment

• Android 8–13 devices

• 3GB–6GB RAM range

• USB-MIDI via OTG

• Chrome (stable channel)

• Web MIDI API enabled

Observed Behavior

After approximately 15–25 minutes of inactivity:

• Initial incoming MIDI events show irregular timestamp offsets

• Short burst of jitter (~15–30ms)

• Stabilization typically occurs after 5–8 event cycles

The issue does not occur during continuous playback.

Interestingly, when replicating the same scenario inside the VN68 test harness, the behavior appears more pronounced on Android 8–9 compared to Android 11+.

Hypotheses

Possible contributing factors:

• OTG polling interval reset after low-power state

• Android kernel power management behavior

• Browser event queue reactivation delay

• USB permission reinitialization timing

Experiments Conducted

• Manually reinitializing USB permission → partially reduces first-spike latency

• Keeping a low-frequency MIDI clock active → reduces drift occurrence

• Disabling battery optimization → inconsistent improvement

Questions for the Community

• Has anyone observed OTG polling instability after extended idle?

• Are there known Android kernel behaviors affecting USB resume timing?

• Would maintaining a lightweight keep-alive clock be considered best practice?

• Any documented Web MIDI scheduling caveats on pre-Android 10 devices?

Interested in real-world implementation insights beyond lab conditions.

Appreciate any shared observations.

In M2-104-UM_v1-1-2_UMP_and_MIDI_2-0_Protocol_Specification of section 7.4.13 Registered Controller (RPN) for Sensitivity of Per-Note Pitch Bend (pp.57), the last sentence:

However, this RPN has no function within the MIDI 1.0 Protocol.

seems to me, 1.0 is typo of 2.0. Is this correct?

Thanks,
M. Suzuki

Working example video: player vimeo com/video/1132810999

Development discussion: gitlab com/lilypond/lilypond/-/merge_requests/2790

In particular, there is a question about needing a System Exclusive ID for the Sequencer-Specific Meta-Events…

gitlab com/lilypond/lilypond/-/merge_requests/2790#note_2897970786

…as described on page 10 of the "Standard MIDI Files 1.0" specification (February 1996).

These IDs are available for a one-time $240 registration fee.
https://midi.org/new-midi-association-sysex-id-policies-as-of-oct-15-2025

There is the 0x7C Limited Non-Commercial ID, for which LilyPond seems to qualify. But it says "The Id… shall not be used… for any of the following mechanisms…" which include "System Exclusive messages with custom or manufacturer defined data format."

Then, found by forum search while writing this post:

If you don't think that your idea or product is worth $240 a year for a SysEx ID, then just give it away. If you want to just innovate and not sell products, there is a range of SysEx IDs available for research and non-commercial use. These have always existed and are documented in the MIDI 1.0 specification.

@"The MIDI Association" : Could this be clarified whether LilyPond needs a SysEx ID, or can use one reserved for non-commercial projects?

Assuming LilyPond needs the SysEx Id, a donor for the $240 can probably be found.

In that case, next question: there is not a legal entity for the LilyPond project. All the developers and community members are participating as individual persons. (As a GNU project, though, there is the upstream Free Software Foundation, a Massachusetts Non-Profit Corporation. How would the SysEx Id registration be expected to work for LilyPond?