Checking access…

WebMIDI Diagnostics

Raw exercises against navigator.requestMIDIAccess() for diagnosing browser-side MIDI quirks (notably iOS WebMIDI Browser).

Environment

1. Request MIDI access

2. List ports

3. Talk to a port

Pick a port from the list (populated by step 2). Both an input and an output with the same name are needed for two-way operations.

4. Program Change & CC

Channel is 1-based (1 – 16). Program 0 = preset 1. HIT, FX 1-6 etc. are CCs configured per device — paste your CC number here.

If HIT doesn't fire on channel 1, try the all-channels broadcast — Play Acoustic's MIDI receive channel is configurable and may not be 1.

5. Send presets

Both write to slot 190 by default — change below if you want a different slot.

6. HIT

Toggles HIT by reading the device's setup, flipping packet 3 byte 41, and writing it back — same path the editor uses. HIT isn't a CC on Play Acoustic.

7. Listen for incoming MIDI (HIT detection / preset change)

Hooks every input port at once and decodes incoming Program Change (preset selection) and Control Change (HIT triggers). Listening on all of them means messages can't be missed if iOS / CoreMIDI bridges the device through a virtual session port instead of the device's own port. Each event is tagged with the port name in square brackets.

idle

External tester flow

The device-discovery + bulk-capture + guided-probe flow lives on its own page now (cleaner UI, no flag gate, public). Open it for testers to use.

Log