Skip to content

docs(spec): 009 note-detection capability domain (draft stub, refs #727)#323

Open
byrongamatos wants to merge 1 commit into
mainfrom
spec/009-note-detection-domain
Open

docs(spec): 009 note-detection capability domain (draft stub, refs #727)#323
byrongamatos wants to merge 1 commit into
mainfrom
spec/009-note-detection-domain

Conversation

@byrongamatos

Copy link
Copy Markdown
Contributor

🗂️ Migrated PR. Originally opened by @mogul on 2026-06-18 (was #516). Review history not preserved.

Reconstructed from slopsmith/slopsmith#728 — original PR by @byrongamatos. Commits replayed with original authorship onto the current main.

Refs #727.

Adds specs/009-note-detection-domain/ (spec.md + plan.md) — a draft stub scheduling the next capability-domain slice after audio-input (006) and audio-monitoring (007).

What it specifies

A per-binding, chart-decoupled, multi-consumer control plane over the existing detection DSP:

  • Exposes two primitives — a monophonic pitch estimate and a polyphonic note-set verification verdict — each scored against a requester-supplied tuning context (so a contained-playback consumer scores against the player's real instrument, not whatever song the host highway has loaded).
  • Consolidates the two fragmented detection surfaces (slopsmithMinigames.scoring.createContinuous mono-YIN + window.noteDetect) behind one contract → one DSP source of truth, so improvements (bass persistence floor, distortion, future models) land once and reach every consumer.
  • Realizes Spec 004's deliberate "no single global detector assumption" via per-binding context.
  • Does not implement DSP and does not own consumer judgment (host owns DSP; consumers own gems/tiers/accuracy).

Why a stub

Per the spec-kit flow, this PR is spec.md + plan.md only; data-model / contracts / tasks are generated when the slice is scheduled, passing the Spec 003 migration gate. It depends on 006 and 007 (007 currently paused at #667), so it isn't startable yet — this fixes the scope and names the requesters now.

Relation to the "work now" bridge

The interim, forward-compatible step is already in flight on the plugin: notedetect setVerifyTarget(notes, ctx) (slopsmith/slopsmith-plugin-notedetect#62), consumed by a SlopScale adapter (fork PR). Its per-call tuning context maps 1:1 onto this domain's per-binding context — the bridge is re-pointed, not discarded, when the domain lands.

No code/runtime changes; docs only.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Documentation
    • Added detailed specification and implementation plan for the Note-Detection capability domain, documenting the architecture for monophonic pitch estimation and polyphonic note verification features with support for per-binding tuning context.

Scheduling placeholder for the next capability-domain slice after audio-input
(006) and audio-monitoring (007): a per-binding, chart-decoupled, multi-consumer
control plane over the existing detection DSP, exposing a monophonic pitch
primitive and a polyphonic note-set verification primitive scored against a
requester-supplied tuning context. Consolidates the two fragmented detection
surfaces (minigames YIN + window.noteDetect) behind one contract; does not
implement DSP or own consumer judgment.

Driven by a real non-chart consumer (SlopScale, Chord Sprint) the current
surfaces can't serve. Interim bridge: notedetect setVerifyTarget(notes, ctx)
(plugin #62), whose per-call context maps onto this domain's per-binding context.

spec.md + plan.md only; full data-model/contracts/tasks on scheduling, per the
Spec 003 migration gate. Refs #727.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
(cherry picked from commit 7b40a63a4656a1d1e473113d83c2927241993702)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants