WebMIDI Test

Introduction

requestMIDIAccess when available and lists input/output ports after any browser permission dialog, without mixing up DeviceHub typed permissions metadata with live OS prompts. Musicians, DAW web app developers, and classroom MIDI labs verify browser-visible controllers before blaming USB hubs or drivers. DeviceHub lists permissions as none in its schema because none records pre-granted Privileged Permissions API categories like microphone, not because browsers stay silent when MIDI access is requested. Real engines may prompt when you ask for MIDI ports; document that separately in support notes while keeping the typed array as none. Safari often lacks Web MIDI entirely, test Chromium or Firefox builds that ship the API. Pair with Web Bluetooth Test when wireless MIDI bridges matter and Browser Features for presence rows. USB hub power issues cause intermittent MIDI enumeration, retry after powered hub before blaming Web MIDI API. Windows ghost MIDI ports from old drivers clutter lists, compare OS MIDI settings with browser enumeration before RMAing controllers. DAW web apps using Web MIDI still need low-latency audio paths, MIDI enumeration success does not certify audio output timing. Classroom Chromebooks after policy updates need smoke before blaming controllers when ports list empty. iOS browsers generally lack Web MIDI, route music students to desktop Chromium lab seats intentionally. Browsers may prompt for MIDI access when requesting ports even though DeviceHub typed permissions stay none, explain both layers in support notes. When requestMIDIAccess runs, browsers may show permission UI even though DeviceHub typed permissions stay none, explain both layers in support notes. Browser tab background throttling does not stop enumeration but may affect sustained clock messages in live performance apps later.

What this tool does

After secure context and user activation, the page requests MIDIAccess, summarizes inputs and outputs when granted or explains denial, and avoids sending MIDI traffic to DeviceHub servers. Port names reflect OS driver labels, rename quirks on Windows versus macOS appear here exactly as the browser exposes them. Bluetooth versus USB MIDI on one controller can list different port sets, connect via intended transport first. DAW web apps using Web MIDI still need low-latency audio paths, MIDI enumeration success does not certify audio output timing. Input and output port counts may differ when controllers expose only performance IN ports to the OS driver stack. Powered USB hubs fix intermittent empty port lists when controllers brown out, retry power before API bugs. Input-only controllers may show fewer output ports, counts differing is normal hardware mapping. Port state change events after hot-plug may require page refresh on some engines; enumeration smoke lists static inputs and outputs at grant time rather than simulating sustained SysEx streams that stress USB bandwidth. MIDI clock and transport messages are not sent during enumeration, DAW sync issues need traffic captures beyond port lists. MPE multidimensional polyphonic expression uses multiple channels, port count alone does not prove MPE routing works in browser synths.

When to use it

Run when browser synths see no controllers, after OS driver updates, when teaching the difference between typed metadata and browser prompts, or when MIDI works in native DAWs but not the web app. Run after macOS privacy prompts for MIDI were denied accidentally, browser site settings may need reset. Web-based piano labs should smoke after overnight Chromebook policy updates before class starts. DAW web apps using Web MIDI still need low-latency audio paths, MIDI enumeration success does not certify audio output timing. Music classrooms reset Chromebook site permissions after semester starts, run Web MIDI smoke before blaming controllers when ports list empty. Safari lacking Web MIDI is platform scope, music labs standardize on Chromium for web synth assignments. SysEx-heavy devices behave same at enumeration, smoke lists ports not sustained traffic performance. Multi-port USB MIDI interfaces may expose duplicate names, use port id strings from browser list when filing hardware bugs. Piano pedal CC messages are not sent during port enumeration, sustain pedal bugs need live MIDI traffic captures beyond this smoke.

How it works

Web MIDI maps OS MIDI devices into port objects; access may require permission prompts per browser policy. HTTPS hosts DeviceHub. Typed permissions stay none while requestMIDIAccess may still show UI, both statements are true in different layers. Disconnect gear before reconnect if ports list stale after sleep. SysEx-heavy controllers behave the same at enumeration, this smoke lists ports, not bandwidth. DAW web apps using Web MIDI still need low-latency audio paths, MIDI enumeration success does not certify audio output timing. Windows ghost MIDI ports from old drivers clutter lists, compare OS MIDI panel with browser enumeration. Revoke MIDI site permission on shared studio machines after sessions when policy requires. Web MIDI SysEx permission when restricted by policy may limit future messages, enumeration still lists port names. Virtual MIDI cable software on Windows adds phantom ports, compare OS MIDI settings when browser lists unexpected duplicate names.

Step-by-step instructions

1. Connect MIDI interfaces before opening Web MIDI Test over HTTPS. Accept browser MIDI permission prompt when shown, typed permissions none metadata still allows real prompts here.
2. Click the control to request MIDIAccess and accept any browser permission prompt, prompts are expected even when DeviceHub typed permissions stay none. Connect controllers before load, then refresh once if hot-plug missed initial enumeration.
3. List input and output ports exposed after access is granted or note clear denial messaging. Close native DAW apps holding exclusive MIDI access before browser port lists populate.
4. If ports are empty, verify OS MIDI settings and that another app is not blocking exclusive access. Use powered hub when classroom controllers brown out and ports flicker empty intermittently.
5. Open Browser Features when navigator.requestMIDIAccess is missing on Safari or stripped WebViews. Document Safari unsupported path, route music labs to Chromium browsers with lab policy approval.
6. Revoke MIDI site permission in browser settings after lab sessions on shared studio machines if policy requires. Revoke MIDI site access on shared studio iMacs after lessons when school policy mandates.

Common problems

Expecting zero browser UI because typed permissions say none misleads support staff, explain both layers. Safari lacking Web MIDI is common. Stale port lists after sleep need refresh or reconnect. USB-only controllers without OS drivers appear nowhere. Windows ghost MIDI devices from uninstalled drivers clutter lists, compare OS MIDI panel with browser list. DAW web apps using Web MIDI still need low-latency audio paths, MIDI enumeration success does not certify audio output timing. Safari lacking Web MIDI entirely is platform scope, direct users to Chromium lab browsers rather than expecting a DeviceHub fix. Bluetooth versus USB MIDI on one controller lists different port sets, connect intended transport first. Connect gear before opening page, hot-plug after load may need refresh to see new ports. Users who deny the browser MIDI prompt once may need site permission reset in chrome://settings/content/midi before ports populate, empty lists after denial are policy outcomes, not controller hardware failure. MIDI 2.0 protocol features when present differ from classic MIDI 1.0 port lists, enumeration smoke lists ports not protocol negotiation.

Privacy explanation

Port names display locally; MIDI performance data is not uploaded during enumeration smoke. Typed permissions none in DeviceHub metadata; browser may retain MIDI site permission until cleared in settings. Shared studio PCs should reset site permissions after class if students connected personal controllers. DAW web apps using Web MIDI still need low-latency audio paths, MIDI enumeration success does not certify audio output timing. Exclusive DAW native access can block browser enumeration, close native apps before Web MIDI smoke. DAW web apps needing low-latency audio still require separate audio path checks beyond MIDI enumeration. USB MIDI class compliance mode on controllers affects dual-port listing, vendor firmware docs define expected port counts.