As I understand it, there is a possible race condition around the initial baseline state.

For example:

1. The Initiator performs Get and obtains the current full state of a resource.
2. The Responder’s resource changes after that Get response.
3. The Initiator sends Subscription Start.
4. The Responder accepts the subscription and then starts sending Subscription Partial updates for subsequent changes.

In this sequence, the change that happened between the initial Get and the Subscription Start may not be observed by the Initiator, unless the Initiator performs another Get after Subscription Start to establish a reliable baseline.

From an interoperability point of view, it seems safest if Initiators are recommended to perform Get after Subscription Start has been accepted, and then apply subsequent Subscription Partial updates on top of that state.

Is there any plan to clarify this in the specification or implementation guidelines?

If this behavior is not recommended or required for Initiators, then as a conservative Responder implementation, I may need to send Subscription Notify immediately after accepting Subscription Start, in order to prompt the Initiator to retrieve the current full state.

However, if both sides behave conservatively, this can result in redundant Gets:

• The Initiator sends Get after Subscription Start to establish the baseline.
• The Responder also sends Subscription Notify after Subscription Start to prompt a Get.
• The Initiator may then perform an additional Get because of the Notify.

This is not necessarily incorrect, but it seems inefficient and could lead to inconsistent implementation patterns between devices.

So my questions are:

1. Is the intended/recommended behavior that an Initiator should perform Get after Subscription Start has been accepted, in order to establish a reliable initial baseline?
2. If so, would it be appropriate to clarify this as a recommended practice in the specification or implementation guidelines?
3. If not, what is the recommended Responder behavior to avoid missed changes around Subscription Start?
4. Should a Responder send Subscription Notify immediately after accepting Subscription Start, or should it avoid doing so to prevent redundant Gets?

My main concern is ensuring that the Initiator and Responder can share a complete and correct resource image without relying on implementation-specific assumptions.

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.