Taking debouncing aside and velocity, a diode matrix scan of 4 rows by 8 columns requires some logic to maintain the pressed notes, that is, once the key event occurs, the note got to be played. Some bookkeeping has to be made, reflecting the fact that it has to be remembered that it had been played. As soon as it disappears from the scan balance, it got to be muted and taken out of the momentarily active notes. etc. etc.

Is this bookkeeping algorithm available somewhere? I'm aware, that reflecting velocity adds some level of complexity.

n is the "block" number, which translates to

0 = CH 10

1 = CH 1

...

9 = CH 9

A = CH 11

...

F = CH 16

It shows

00 at n!=0

01 at n=0

Does this mean that channel 10 (n=0) CAN NOT be assigned as a non-percussion part?  I am testing a file with the SYSEX command to set CH 10 to non-percussion, but my software is still playing it as percussion.

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.

This is not a commercial release, but rather a controlled environment used to simulate multi-channel MIDI routing and real-time interaction.

Test Environment

Android

• Android 6.0 – 13

• 2GB–6GB RAM devices

• USB-MIDI via OTG

• Chrome (latest stable)

iOS

• iOS 12+

• CoreMIDI compatible devices

• Safari (latest)

Web

• Web MIDI API enabled

• PWA mode with offline cache

Observed Performance Metrics

Under standard conditions:

• Event processing latency: 8–14ms (USB-MIDI direct input)

• UI rendering: Stable 60FPS on mid-range devices

• Multi-channel routing: No noticeable jitter under 4-channel simulation

• Session encryption: AES-256 handshake (for preset sync validation testing)

Latency variance appears to increase when background processes are active, especially on Android 6–8 devices.

Installation Context (Test Build)

Android test build (~75MB APK):

• Signed package (SHA-256 checksum verified)

• Requires network + storage permissions

• USB device authorization required at runtime

iOS deployment:

• Distributed via TestFlight

• CoreMIDI authorization on first launch

Web fallback:

• Progressive Web App mode

• Add-to-home-screen supported

• Offline event logging enabled

Interesting Findings

1. Web MIDI performance on Android 6–8 shows greater timing drift compared to Android 10+.

2. Chrome seems to manage buffer scheduling more consistently than some Chromium-based alternatives.

3. USB permission reinitialization sometimes reduces latency spikes after extended idle time.

Open Questions for the Community

• Has anyone benchmarked Web MIDI API latency across older Android devices?

• Are there recommended buffer strategies to reduce 10–15ms fluctuation?

• Any known limitations of OTG MIDI handling on low-RAM devices?

• Best practices for stabilizing event timing in PWA environments?

I’m particularly interested in real-world field testing beyond lab measurements.

Appreciate any insight or shared benchmark data.

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