3 Commits

Include renames

Author	SHA1	Message	Date
gionnibgudandGitHub	eef58c88c3	feat(sloppak): core reader for source rigs (feedpak 1.18.0) (#1040) ... * Carry rig bindings through the sloppak tone payload `sloppak_tone_changes` emitted `{t, name}` only, so a chart's declared sound never reached the client: `base_rig` was never read and each change's `rig` was dropped at the wire boundary. Both survive load intact (`Arrangement.tones` is an opaque passthrough) — the strip happened here, at the last step before send. That left the rig model (feedpak-spec 1.18.0 §6.9/§7.9) unreachable from core: a pack could declare which rig voices a part, and nothing downstream could ever see it. First step of the core reader for source rigs; the rig library itself and the manifest precedence cascade follow. Return `(base, base_rig, changes)` and keep `rig` on each change. Both ids are validated as non-blank strings and stripped — anything else is dropped rather than forwarded, so presence of the key means the change binds a rig. Resolution against `rigs.json` deliberately does NOT happen here: this builder preserves the declared binding, while realization selection and the `intent.gm` fallback belong to whatever voices the part. On the wire `base_rig` is omitted entirely when empty, so packs that bind no rig produce the byte-identical `tone_changes` message they always did. Signed-off-by: gionnibgud <gionnibgud@gmail.com> * Load the pack's rig library from the manifest feedpak 1.18.0 lets a chart declare what a MIDI part should sound like by binding a rig id, but core had nothing to bind to: `rigs`, `base_rig` and `drum_tones` appeared nowhere in lib/, server.py or static/. The preceding commit carries the reference onto the wire; this adds the library it references. Read the manifest `rigs:` key into a new `LoadedSloppak.rigs`, alongside the other side-files rather than on Song — every side-file (drum_tab, song_timeline, keys, notation) hangs off the load result, and rigs is pack-level, not per-arrangement. Same permissive posture as its neighbours: missing, unreadable, malformed or traversing disables rigs with a warning and never fails the pack, which §7.9 requires outright. Rig objects pass through VERBATIM. §7.9 obliges a Reader to preserve unknown role/engine/kind values and `ext` namespaces, so validating block structure here would be wrong as well as premature — realization selection and the `intent.gm` floor belong to whatever voices the part. The only entries dropped are ones unreachable by construction: a rig is addressable solely by `id`, so a non-dict entry or one without a usable string id can never be referenced. Ids are stripped to match the reference side, and a duplicate id resolves first-wins with a warning, since ambiguity there would surface as the wrong sound rather than an error. Signed-off-by: gionnibgud <gionnibgud@gmail.com> * Resolve which tones block binds a part feedpak 1.18.0 lets a sound binding arrive from three places, and core honoured none of them: the manifest arrangement entry, the arrangement JSON, and the top-level drum_tones. Reading them needs a precedence rule, because two of the three can be present at once. Arrangement entries: the entry's `tones` replaces the arrangement JSON's WHOLESALE (spec 5.2), unlike name/tuning/capo/centOffset beside it, which override field by field. A merge would produce a sound nobody authored -- one source's base under the other's changes -- which is worse than either block alone. This is also what makes a notation-only keys entry bindable at all, since it has no arrangement JSON to carry tones in the first place. Drums: the top-level drum_tones binds the song-level primary part, and a `type: drums` entry's own tones takes precedence, with a Reader forbidden from applying both to the same part (5.1). That is the same shape as the drum_tab alias rule, so it lives inside _resolve_drum_parts next to it rather than beside it -- one precedence resolver, not two that drift. drum_tones is the PRIMARY's fallback only: a second drummer with no binding gets None, never the primary's kit. An empty `tones: {}` reads as absent rather than as an override to silence, matching how arrangement_from_wire already normalizes the in-JSON empty dict, so a stray empty object cannot quietly unbind a part. Spec-conformance gate passes with drum_tones added to the keys core reads (22 of the spec's 32, all declared). Signed-off-by: gionnibgud <gionnibgud@gmail.com> * Document the rig bindings on the tone_changes wire message CHANGELOG entry for the core rig reader, plus the WS protocol table in CLAUDE.md, which described `tone_changes` as carrying only base + name. While in that row: its time key was documented as `time`, but every producer emits `t` — both the sloppak builder and the legacy XML path. The 3D highway already carries a comment warning readers about exactly this discrepancy. Corrected here rather than left sitting next to the newly-added keys, where a reader would reasonably assume both were equally reliable. Signed-off-by: gionnibgud <gionnibgud@gmail.com> --------- Signed-off-by: gionnibgud <gionnibgud@gmail.com>	2026-07-23 11:27:21 +02:00
4 people	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
byrongamatos	6c110398b4	Clean release snapshot	2026-06-16 18:47:13 +02:00