Current listening boundary · Ear is governed as a Web Audio graph observer with MIDI2 output; runtime and device acceptance remain separate.

138 — Ear Is the Web Audio Graph's MIDI2 Listening Boundary

Ear observes explicitly connected Web Audio sources, including other AudioWorklets, and emits validated MIDI2 UMP without becoming a microphone-only or second protocol authority.

Principal illustration — the governed graph boundary. It shows explicit source connection and MIDI2 observation; it is not proof of browser interoperability, physical audibility, microphone permission, or a completed Ear runtime.

The decision

Ear is a listening instrument for the Web Audio graph. A microphone is one possible source, alongside Csound or WebAssembly output, Teatro's mix, media elements, audio buffers, and the output of another AudioWorkletNode. Every source Ear observes must be explicitly connected to an Ear input or analysis tap. Ear cannot discover or inspect unrelated AudioWorklets merely because they exist in the same page.

microphone ───────┐
Teatro/Csound ────┼──► explicit Web Audio tap ─► Ear AudioWorklet ─► MIDI2 UMP output
other worklet ────┘                                  │
                                                     └──► MIDI2 witness telemetry

What Ear observes

Ear may measure energy, onset, pitch, modulation, turbulence, and other declared features from each connected input. The analysis window, hop, timestamp origin, confidence, and source identity are explicit. Silence, unavailable input, and unsupported detection are typed results, never guessed notes.

The output remains the existing MIDI2 UMP representation and validation path. Where the detector supports it, group, channel, note, 32-bit velocity, pitch, per-note expression, and event timestamps remain intact. Ear introduces no JSON transport and no MIDI1 downgrade.

Rules

1. Ear is a Web Audio graph observer, not a microphone-only product.
2. Only explicitly connected graph inputs are observable; unrelated AudioWorklets remain outside Ear's authority.
3. Analysis runs in an AudioWorklet boundary, never in the UI thread's render or event handler.
4. Ear consumes and emits the existing MIDI2 UMP representation and public midi2.js APIs.
5. Measurements, emitted events, queue pressure, dropped windows, and lifecycle transitions remain observable through the existing MIDI2 telemetry contract.
6. A GUI state, analyser value, or queued event is not proof that a person heard sound.
7. Initialization, permission, connection, running, unavailable, interrupted, backpressure, error, and shutdown are typed states with deterministic cleanup.
8. Browser MIDI2 delivery, physical output, and device interoperability require independent acceptance evidence.

Acceptance boundary

The executable scenario must prove that a connected non-microphone AudioWorklet source reaches Ear; a microphone is optional; validated MIDI2 UMP preserves timestamp and source identity; same-window ordering and backpressure are deterministic; unavailable MIDI2 output does not convert to MIDI1; telemetry correlates measurements and lifecycle; and shutdown releases every connected node, MessagePort, timer, and retained event buffer.

Governing sentence

Ear gives the Web Audio graph a MIDI2 listening boundary: connect the sound explicitly, analyze it off the UI thread, emit what the graph can justify, and let acceptance—not a visible meter—say what was actually heard or delivered.