af2949677a
* 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>
3.9 KiB
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-inputowns: 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-controlwill 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 amidi-inputsession for the live stream; it never callsrequestMIDIAccessor enumerates devices.
Proposed contract (for the future implementation slice)
- Owner:
core.midi-control(or a first-party MIDI-control plugin),multi-provider, safetysensitive. - 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-inputsession, 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 adoptmidi-controlto 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).