Files
feedBack/specs/013-midi-control-mappings/spec.md
T
af2949677a rename: slopsmith → feedBack, byron → got-feedBack (#537)
* Update GitHub repo references from feedback* to feedBack*

* rename: slopsmith -> feedBack, byron -> got-feedBack

Renames across the entire codebase:
- slopsmith/Slopsmith/SLOPSMITH/SlopSmith -> feedBack/FeedBack/FEEDBACK/FeedBack
- byron/Byron/Byrongamatos -> got-feedBack/got-feedBack/got-feedBack
- /home/byron/ -> /opt/got-feedBack/
- byron@ougsoft.com -> hi@got-feedBack.org
- github.com/byrongamatos/ -> github.com/got-feedback/
- com.byron. -> com.got-feedback.
- SLOPSMITH_ env vars -> FEEDBACK_ with backward-compat fallback
- Protocol/storage strings migrated with read-old/write-new pattern
- window.slopsmith JS API -> window.feedBack (canonical) + backward-compat alias

Refs: #rename-slopsmith

* rename: complete regen against current main + fix backward-compat alias

Regenerated the slopsmith->feedBack / byron->got-feedBack rename on top of
current main (3 commits had landed since the branch: #572/#554/#574),
resolving the four content conflicts in favour of main's newer content
(autoplay/auto-exit, accuracy-badge, Virtuoso re-home, feedpak badge).

Completion fixes on top of the mechanical rename:
- Re-apply rename to post-branch content the original rename never saw:
  window.slopsmith(.Tour) consumers in lessons.js / notifications.js /
  onboarding-tour.js, and the matching JS + python tests (autoplay_exit,
  progression_*, test_feedpak_extension FEEDBACK_* env vars). The test env
  vars now match server.py (which reads FEEDBACK_SYNC_STARTUP /
  FEEDBACK_SKIP_STARTUP_TASKS), so the sync-startup test exercises the real
  path again.
- Restore the window.slopsmith backward-compat alias dropped during conflict
  resolution, and move the bus aliases to AFTER the _feedBackExisting merge
  block so they reference the fully-assembled object (also fixes the
  loop_api.test.js API-surface regex, which the original PR latently broke).
- Drop the stray empty data/web_library.db (runtime DB lives in CONFIG_DIR)
  and gitignore it.
- Fix stale tone-source test: feed[dB]ack -> fee[dB]ack to match shipped
  source labels.

Verified locally (org CI billing-blocked): JS 819/819 pass; pytest 1669
passed / 1683 collected with 0 import errors; zero residual slopsmith/byron
except the two intentional window.slopsmith aliases.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* rename: implement advertised backward-compat + prune dead community plugins

Address gaps where PR #537's "Backward compatibility" section was advertised
but not implemented, and clean up the community plugin list.

Env vars (FEEDBACK_* canonical, legacy SLOPSMITH_* honoured):
- New lib/env_compat.py (getenv_compat / env_flag_compat) + tests. server.py
  (_env_flag + all FEEDBACK_* reads), diagnostics_hardware, gp2midi and
  tailwind_rebuild now resolve the legacy alias, so existing SLOPSMITH_UI /
  SLOPSMITH_PLUGINS_DIR / etc. deployments keep working.
- Fix the rename collapsing plugins/__init__.py and minigames/routes.py from
  `FEEDBACK_PLUGINS_DIR or SLOPSMITH_PLUGINS_DIR` into a redundant
  `FEEDBACK_ or FEEDBACK_` (the fallback was silently lost).

Storage (app.js update-channel):
- Read feedBack-update-channel, fall back to legacy slopsmith-update-channel,
  and clear the legacy key on write — so a user's update-channel preference
  survives the rename instead of resetting to "stable".

Community plugin list (README): the rename rewrote third-party repo URLs we
don't own. Probed every one; their owners never renamed, so:
- Restore the 13 live community plugins to their real slopsmith-* names.
- Prune 6 that are 404 to the public (topkoa splitscreen/stems, OmikronApex
  tuner, Jafz2001 nam-rig-builder, DeathlySin song-preview, Erikcb91 shuffle).
- Fix a pre-existing Guitar Theory clone-command typo (nam-tone -> guitar-theory).

Verified: env_compat 7/7, JS 819/819, pytest 1690 collected / 0 import errors,
rename-sensitive + startup suites green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: byrongamatos <xasiklas@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-23 11:03:01 +02:00

76 lines
3.9 KiB
Markdown

# Spec 013 — `midi-control` Mappings Domain (the midi-input/midi-control split)
**Status:** documented future contract (RESERVED — not in the runtime graph) ·
**Issue:** #882 · **Depends on:** spec 012 (`midi-input`, delivered) · **Base:** `feedback/main`
## Summary
`midi-control` is the planned sibling of `midi-input`: it owns **MIDI control
mappings** — routing CC / pitchbend / note messages to *semantic actions* (drum
lane, transport command, effect parameter, etc.) — and **consumes `midi-input`**
for device access. It does **not** discover, select, or open devices; that is
`midi-input`'s job (spec 012, delivered).
This spec records the **split** so the boundary is unambiguous and the contract
is ready for whoever builds the runtime slice. Per project governance
(`docs/capability-safety-matrix.md`, `docs/capability-roadmap.md`), a future
domain stays **documentation-only until a PR ships its host workflow, a concrete
consumer, and tests** — so `midi-control` remains `RESERVED` in
`static/capabilities.js` `RESERVED_FUTURE_DOMAINS` until then. This spec does not
register a runtime domain.
## Why split it out
Before `midi-input` existed, "MIDI" meant two conflated concerns: getting bytes
from a device, and mapping those bytes to actions. The reserved `midi-control`
entry originally covered both. With `midi-input` delivered as the device control
plane, `midi-control` is narrowed to **mappings only** — mirroring how
`audio-input` (devices) is separate from `audio-effects`/`audio-mix` (what you do
with the signal). Keeping them separate prevents a future god-domain and lets the
device plane stabilize independently of mapping semantics.
## Boundary (normative)
- **`midi-input` owns:** device discovery (`discover`), source list, selection,
open/close sessions, the Web-MIDI permission boundary, redacted device
diagnostics. The raw MIDI message stream is delivered to in-page consumers via
its session handle.
- **`midi-control` will own:** named mappings from MIDI events (note / CC /
pitchbend, optionally channel-scoped) to semantic actions, mapping persistence,
active-mapping selection, and "learn" capture. It **consumes** a `midi-input`
session for the live stream; it never calls `requestMIDIAccess` or enumerates
devices.
## Proposed contract (for the future implementation slice)
- **Owner:** `core.midi-control` (or a first-party MIDI-control plugin),
`multi-provider`, safety `sensitive`.
- **Commands:** `list-mappings`, `get-mapping`, `set-mapping`, `delete-mapping`,
`activate-mapping`, `inspect`.
- **Mapping shape (sketch):** `{ id, label, trigger: { type: 'note'|'cc'|'pitchbend',
number?, channel? }, action: { domain?, command?|actionId, params? } }`.
- **Learn mode:** open a `midi-input` session, capture the next matching event,
and bind it to the pending action (the per-plugin "learn" UIs in drums today
are the reference behaviour to generalise).
- **Diagnostics:** `feedBack.midi_control.diagnostics.v1` — mapping summaries +
bounded recent activations; **no raw MIDI streams, no device labels**.
## Intended consumers (promotion trigger)
The domain should be promoted out of RESERVED when a concrete consumer needs
shared mappings, e.g.:
- the generic **MIDI control plugin** (`feedback-plugin-midi`) — today an ad-hoc
event→action mapper; the canonical first adopter.
- **drums** note→lane mapping + "learn mode" (`feedback-plugin-drums`,
`feedback-plugin-drum-highway-3d`) — currently per-plugin; could adopt
`midi-control` to share mapping logic once the contract is proven.
Until such a consumer-driven slice exists (with host workflow + tests), this
remains a documented contract only.
## Out of scope
- Any runtime registration / handlers (governance: no premature domain).
- Migrating the drums/keys per-plugin mapping now — deferred to the consumer slice.
- The device plane — owned by `midi-input` (spec 012, done).