7 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
3 people	e0270e5c30	fix(song): make bass detection instrument-type-aware, not name-only (#1019) ... Editor now authors an arrangement's instrument as first-class data (a manifest 'type' field). Core dropped it: the sloppak loader never read 'type', and 'is this a bass?' was defined three different ways across call sites (name-only in note_pitch_midi and the highway scale-degree path; path_bass+name in bass selection; name-only in arrangement_string_count). So an authored type=bass chart not named 'bass' got 6-string lane counts and guitar open-string MIDI. - Add optional Arrangement.type; sloppak load_song lifts the manifest type onto it - Add arrangement_is_bass(arr) = type=='bass' OR path_bass OR 'bass' in name (None/whitespace safe), and route string count, note_pitch_midi, the highway scale-degree base, and bass-player selection through it - Back-compat: no bass signal -> unchanged 6-string / guitar behavior Companion to editor #335 (first-class instrument type). Scale degrees are display-only and never feed a grader. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 13:30:54 +02:00
4 people	605dbdfd25	feat(sloppak): load multiple drum parts (feedpak 1.17.0 drums-as-arrangements) (#1020) ... * feat(sloppak): load multiple drum parts (feedpak 1.17.0 drums-as-arrangements) A song can now ship SEVERAL drum charts (a second drummer, an aux-percussion layer). The Arrangement Editor already writes them per the feedpak 1.17.0 FEP (feedpak-spec#63): the primary stays the song-level `drum_tab:` key (what this app has always played), and each part rides the manifest as a `type: drums` arrangement entry carrying a per-arrangement `drum_tab` file pointer and NO note `file` — an entry this loader's file/notation gate already skips, which is exactly why old builds are unaffected by such packs. lib/sloppak.py: - The arrangements loop collects drum-part pointer entries instead of merely skipping them — but still NEVER turns one into a fretted Arrangement. That skip is the grading invariant (an empty drum chart must not reach the fretted pipeline / note-detection grading) and is now pinned by test. - New `LoadedSloppak.drum_parts`: [{id, name, drum_tab}], primary FIRST. The entry aliasing the song-level file contributes its id/name but is never loaded twice (the primary's payload IS `loaded.drum_tab`, same object). Legacy single-drum packs read as a one-part list; a pointer-only pack (a writer omitted the alias) promotes its first part so has_drum_tab, the default stream, and the drum-only placeholder keep working. - The song-level drum_tab loading block is extracted verbatim into `_load_drum_tab_file()` and shared by both paths, so every part gets the same permissive posture: missing file → that part silently absent; traversal / parse / validation failure → that part skipped with a warning, never an aborted load. (The 9 pinned drumtab-load tests pass unchanged.) lib/routers/ws_highway.py: - `song_info` gains `drum_parts` (names only; always a list, empty without drums) so a part picker can bind unconditionally. - `?drum_part=<id>` on the WS URL selects which part's tab streams as the `drum_tab`/`drum_hits` messages; the default and any unknown id fall back to the primary — byte-identical legacy behavior. The `drum_tab` message carries `part_id` only when a parts list exists, keeping the legacy frame unchanged. Tests: tests/test_sloppak_drum_parts.py (9) — the grading invariant + parallel-ids pin, primary-first resolution with alias identity, legacy one-part list, pointer-only promotion, per-part failure isolation (bad JSON, path traversal, duplicate rels), and the drum-only placeholder with pointer entries. Full suite: the only failures are 9 machine-environmental tests (installed desktop plugins under LOCALAPPDATA, CRLF/path-shape assertions) that fail identically on an untouched origin/main checkout on this box. tools/check_spec_conformance.py passes against the spec's current HEAD (`drum_tab` and `type` are declared keys); the semantics of the per-arrangement placement land in feedpak-spec#63 — this PR should merge after it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017xGPjDBF8NTwTK7VQvizix Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> * Fix drum-part review findings * Normalize drum part pointer identities * fix(sloppak): enforce drums grading invariant + green the suite - Gate the drum-pointer skip on type FIRST: a type:drums/drum entry never becomes a fretted Arrangement even if it carries a note file/notation (with drum_tab it is collected as a drum part, without it dropped+warned). Closes the spec §5.2/§7.5 MUST-NOT hole (a malformed drums+file entry was being fretted-graded). - Make test_drum_pointer_with_wrong_type_logs_warning robust (attach handler to the feedBack logger + set WARNING, restore in finally) and fix the root-cause level leak in test_tuning_provider_isolation.py (finally restored the handler but not the level, leaking ERROR onto the feedBack tree and turning the suite red under full ordering). - Restore the chart-transform CHANGELOG bullet (#952) the drum entry had truncated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: byrongamatos <xasiklas@gmail.com>	2026-07-21 13:27:41 +02:00
3 people	35c0d0ea0d	Pass per-stem name/description through to the stems payloads (#1013) ... feedpak 1.16.0 (spec §5.3) added two OPTIONAL presentational fields to a stems[] entry: `name` (display label, Readers fall back to the id) and `description` (free text). The server dropped both while normalizing manifest stems, so no client could ever display them. Pass them through at the one place stem descriptors are built (sloppak.load_song) and let both payload builders — the WS `ready` stems list and the REST `/api/song/{f}?stems=1` preload list, which are pinned against each other by test — carry them forward. Omit-when-absent, so a stem without the fields does not grow null keys; non-string or blank values are dropped rather than surfaced. No behaviour change for existing packs or clients: the fields are additive and every consumer that reads {id,url,default} keeps working unchanged. The stems plugin / stem mixer display work lands separately. Signed-off-by: topkoa <topkoa@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 11:45:16 -04:00
3 people	329cc86315	fix(sloppak): the full mix is a stem — drop the invented original_audio key (#946) ... * fix(sloppak): the full mix is a stem — drop the invented `original_audio` key (#933) Core read, served, and depended on `original_audio:` — a top-level manifest key this repo invented in #583 that the feedpak spec never defined. The format already had a home for the pre-separation mixdown: it is a stem. feedpak 1.15.0 (feedpak-spec#53) RESERVES the id `full` for it, so read it from there. The key existed to work around a bug in our own reader. The packer's comment said so plainly: "we must NOT list the full mix as a playable stem — the player sums every entry in `stems` and does not gate playback on `default`, so a listed full mix plays on top of the stems". Faced with a reader that would double the song, the packer put the mixdown outside `stems` and invented a key to point at it. The fix belongs in the reader, and that is what this is. load_song() now partitions the stem list: `full` comes out as LoadedSloppak.full_mix, the instruments stay in .stems. Nothing that sums stems or draws one fader per stem can see the mixdown, so retaining it is safe — which is what lets the packer put it where the format says it goes. - ws_highway: `song_info` gains full_mix_url / has_full_mix. The old original_audio_url / has_original_audio remain as deprecated aliases for one release so an older stems plugin keeps working (#945). - `stems` on the wire, and stem_ids / stem_count in the library index, are now INSTRUMENT stems only — a separated pack that retains its mixdown no longer advertises a bogus "full" chip or an inflated stem count. - enrichment: fingerprint against the mixdown wherever it lives. This widens coverage — _song_audio_file() previously returned None for any pack without the invented key, so fingerprinting silently did nothing for nearly every pack. - sloppak: `original_audio:` is still READ as a deprecated fallback, because every pack in the wild carries it and would otherwise lose its pristine mix. tools/migrate_full_mix_stem.py rewrites those packs into the spec shape (original/full.ogg -> stems/full.ogg, add the `full` stem at default:off, drop the key); the fallback and the aliases die with #945. The spec gate keeps the debt honest: the grandfather entry now tracks #945, and the gate fails if it goes stale. Verified: spec gate OK (4/4, incl. ingesting the spec's new example pack that retains `full`); 2493 python tests, 995 js tests; migrator round-tripped over real packs from the library and the results pass the spec's reference validator. * fix(migrate): discover directory-form packs instead of silently skipping them iter_packs() searched only files, so a directory-form pack (`song.sloppak/`, the authoring shape) was walked INTO and never yielded — silently missed by a run that's meant to be exhaustive. Discover suffix-named directories too (yielded whole, not descended into), and route packs through migrate_pack/verify_pack. Directory packs are REPORTED as `dir-form-unsupported`, not rewritten in place: a single-file pack is replaced atomically (a fully-built temp archive swapped in with one os.replace), but a populated directory can't be swapped that way, so an interrupted in-place rewrite could leave an authoring pack half-migrated. The status is a problem status, so it counts against the run's exit code and shows in the summary — the operator re-packs or migrates it as a `.feedpak` instead of it vanishing from the report. Addresses a CodeRabbit review finding. Signed-off-by: Kris Anderson <topkoa@gmail.com> * fix(migrate): verify requires an explicit `off` on a retained full mix verify_zip accepted any non-truthy `default` on a multi-stem `full` (missing, empty, boolean, `false`/`no`/`0`, malformed) as "ok". But core defaults an ABSENT `default` to True — ON (lib/sloppak.py: `s.get("default", True)`) — and treats an empty/unrecognized string as ON too, so a migrated-shape pack whose `full` stem has a missing or blank default beside instrument stems would actually play the mixdown on open and double the song. verify was certifying that as safe. Require an explicit normalized `off` beside instrument stems: `on`-ish values are reported `full-stem-default-on` (actively plays), everything that is not a normalized `off` is reported `full-stem-default-not-off`. The migrator already writes the literal `off`, so its own output is unaffected; this also certifies the pack is in the tool's canonical, most-portable shape. The len>1 gate is kept, so a sole `full` stem (which IS the audio) is not policed. Adds parametrized coverage for missing / empty / boolean / off-ish / malformed defaults, and a sole-full-stem case. Addresses a CodeRabbit review finding. Signed-off-by: Kris Anderson <topkoa@gmail.com> --------- Signed-off-by: Kris Anderson <topkoa@gmail.com> Co-authored-by: Kris Anderson <topkoa@gmail.com>	2026-07-13 12:22:42 -04:00
3 people	c8701991cb	fix(ws_highway): swallow a mid-stream WebSocketDisconnect quietly (#845) ... * fix(ws_highway): swallow a mid-stream WebSocketDisconnect quietly Pre-existing (byte-identical to origin/main), flagged by CodeRabbit on #844: the outer try's only guard was `except Exception as e: log.exception("highway_ws unhandled error")`. The inner `except WebSocketDisconnect` covers ONLY the post-`ready` keep-alive loop, and the drum_tab/notation sends have their own localized guards — but the ~13 other streamed sends (beats, sections, notes, chords, anchors, …) fall through to the blanket handler. Since WebSocketDisconnect is an Exception subclass, a routine tab-close mid-load was logged as an error at whichever send was in flight. Fix: a dedicated `except WebSocketDisconnect: return` before the blanket handler, matching the two localized guards and the lib/ coding guideline. tests/test_ws_highway_disconnect.py drives highway_ws with a fake websocket that raises WebSocketDisconnect on the first streamed send (`loading`), over a real minimal sloppak. Negative-checked: removing the guard makes it fail (the disconnect is logged as `highway_ws unhandled error`); the fix passes. Uses a raw handler on `feedBack.server` rather than caplog, since configure_logging() reroutes that logger through structlog where caplog doesn't observe it. Full suite green. Closes the review thread on #844. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(ws_highway): assert streaming stops after disconnect (exactly one send) — CodeRabbit The stub now raises only on the first send and the test asserts ws.sends == 1, so a handler that caught the disconnect and kept streaming would fail. Still negative-checked: removing the guard fails the test. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-10 21:30:53 +02:00
3 people	514461167e	refactor(server): extract the highway WebSocket into routers/ws_highway.py (R3) (#844) ... The single largest handler in server.py — the 902-line /ws/highway/{filename} chart streamer — plus its 3 exclusive helpers (_pick_smart_arrangement, _sanitize_authors, _sanitized_song_offset). server.py: 9,008 -> 8,003 (-1,005, the biggest single R3 cut). Clean move despite the size: the handler's only server-module deps are the 4 path constants + 3 exclusive helpers + app + log. Everything else it uses is either NESTED inside the handler (_evict_audio_cache, _fill_scale_degree, _manifest_entries, _tone_names, _xml_rank, _send_keepalives) or imported from the shared lib modules (song/audio/sloppak/drums/notation/dlc_paths/metadata_db). - Path constants read through the appstate seam: added static_dir / sloppak_cache_dir / audio_cache_dir slots (config_dir already there); server.py configures them. Bodies otherwise verbatim (@app.websocket -> @router.websocket, PATHS -> appstate.*, log -> module logger). - sloppak_cache_dir IS setattr-patched, so the 3 test_highway_ws_* suites now also `setattr(appstate, "sloppak_cache_dir", ...)` next to their existing server patch. _sanitize_authors unit tests import it from routers.ws_highway (it moved). No other test churn. - Removed 23 now-dead imports from server.py (song/audio/drums/notation/ bisect/contextvars/structlog/WebSocket*/_arr_smart_sort_key) — diffed against the origin/main unused-import baseline so only NEWLY-dead ones went. owns_tmp (assigned, never read) moved verbatim — it's pre-existing dead on origin/main too; left as-is to keep the move faithful. Verified: route table identical to origin/main (143, paths/methods/order); handler body verbatim spot-checked; pyflakes clean (server has no new undefined/dead); pytest 2400 passed; packaging guard 53; eslint 0. Boot smoke: the highway WS streams the full chart (song_info/beats/sections/notes/chords/ notation/anchors/drum_tab -> ready) BYTE-for-byte the same message sequence as origin/main across arrangements 0/1/2, zero tracebacks. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-10 21:12:54 +02:00