25 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
gionnibgudandGitHub	1a7e2bf084	Extract the pack-path containment guard into one helper (#1039) ... Every manifest key that names a file carried its own copy of the same traversal guard: resolve, prove containment under source_dir, warn and skip on ValueError, warn and skip on OSError. Seven copies — original_audio, drum_tab, arrangement, notation, song_timeline, lyrics, keys — which is seven chances for the next side-file to get a security check subtly wrong by copying the wrong neighbour. Route them all through `_resolve_pack_path(source_dir, rel, label)`. Deliberately preserved, because each was load-bearing: - Both exception branches, with their different messages. ValueError means the path resolved outside the pack (a crafted or broken manifest); OSError means it could not be resolved at all (symlink loop, permissions). They send an operator to different places. - Per-call-site control flow. The helper returns `Path | None` and says nothing about what to do next, so the two sites that return, the one that continues, and the four that fall through to an `is not None` test each keep the shape they had. - The existence-check asymmetry. Some sites test `.exists()` (or `.is_file()`) after resolving and some do not, which is intentional — a missing optional side-file is silent, a missing arrangement skips an entry — so existence stays out of the helper entirely. Pure refactor: no behaviour change and no new validation. Log output is byte-identical (the hardcoded labels become a `%s` argument rendering to the same text). Full suite is unchanged at 2774 passed / 4 skipped before and after, and the five loader-level traversal tests that used to cover five separate copies of the guard now all exercise the same function. Signed-off-by: gionnibgud <gionnibgud@gmail.com>	2026-07-23 11:26:35 +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	cc75cb876a	fix(library): tuning filter answers for your instrument, not always guitar (#1003) ... * fix(library): tuning filter answers for your instrument, not always guitar The library indexed exactly one tuning per song, chosen guitar-first (lead > rhythm > combo, bass only as a last resort), and nothing consulted the player's instrument. A bassist filtering by tuning was shown the guitar chart's tuning, so playlists built by tuning contained songs needing a retune. Reported by a tester building bass practice sets; Covet "Shibuya" is the clean case, with a custom guitar tuning over a standard bass chart. Indexes each arrangement role's own tuning and makes the facet, filter, sort and labels answer for one perspective. `guitar-lead` reads the original unprefixed columns and adds no payload keys, so the default response is unchanged. The same defect existed inside guitar -- lead and rhythm charts can disagree -- so perspective is three-valued (guitar-lead, guitar-rhythm, bass) driven by one PERSPECTIVES table rather than parallel column families. Songs with no chart for the perspective fall back to the song-level tuning rather than vanishing (18 of 59 packs in the test library have no bass chart), but the fallback is marked inferred in the facet counts and on the row instead of being silently coalesced. "Only real charts" reuses the existing `arrangements_has` filter rather than adding one. Bass-specific handling, from measured content: - Bass tuning arrays are padded to six entries; charts never reference string index 4 or 5. Truncated to four before naming and grouping. - Grouping uses a canonical open-pitch key, so [-2,0,0,0] and [-2,0,0,0,0,0] are one facet row instead of two. - Offsets above +1 semitone are refused a name. Bassists tune down, near never up; one pack ships [5,5,5,5,4,4] (A-D-G-C, unplayable, and its own notes sit in the song's real key under standard tuning). Naming that would send a player to retune to a tuning that does not exist. Rhythm deliberately does not truncate -- padding is a bass finding, and cutting a seven-string array would invent a tuning the chart lacks. Adds an opt-in `tuning_match=playable` mode alongside exact match: a chart is offered when your lowest open pitch is at or below its lowest open pitch, so a five-string bass covers four-string standard and drop-D with no retune. Open strings only -- note range is not indexed and the scan stays manifest-only -- so it fails conservative: unknown low pitch is excluded, and the upper bound is unchecked and documented rather than guessed. Existing installs would otherwise never populate: the tree-signature fast path reports "unchanged" forever on a settled library. Rows with NULL marker columns re-extract, and the fast path is disabled until that backfill converges (writes use '' rather than NULL, so it self-clears). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SFDokqh2H6mEjk1Kgbi6JW Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> * test(v3): accept the tuning-perspective indirection in the badge guard The album-art badge now reads shownTuningName(), so the source-pattern guard no longer matched the inline `tuning_name || tuning` form and CI went red. Accept the helper, and pin the helper's own fallback in a companion test so the guard still fails if a guitar player's tuning label is ever dropped. Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> --------- Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 00:04:30 -05:00
Byron GamatosandGitHub	939c98214b	feat(song-info): publish the playable stem list so stems can preload (fixes the 698ms freeze) (#972) ... * feat(song-info): publish the playable stem list, so stems can preload The stems plugin could only learn its stem list from the highway's WS `ready`, which arrives once the highway is already up. So it fetched, decoded, and then handed every stem's PCM to its audio worklet — copying the WHOLE SONG — with the player already on screen. For a 4-minute 6-stem pack that is over half a GIGABYTE of memcpy, in one frame, on the main thread. Measured on a real load: a 698 ms frame, right as the song-credits card appeared, with the venue video visibly stopping. That is the "the video pauses when the author appears" report. GET /api/song/{f}?stems=1 now returns the same list — [{id, url, default}] plus full_mix_url — so the plugin can start the whole load at `song:loading`, before the highway (and the venue) is drawn, where a stalled frame costs nothing. Nothing about the work changes; only WHEN. Opt-in via the query param so the library's own metadata calls — the hot path — pay nothing. Deliberately NOT stored in the metadata cache: that is a fixed-column table, and widening it would mean a schema migration plus a stale row for every song already scanned, to cache something that is a plain manifest read on an already-unpacked pack. The safety property: REST and the WS must publish the SAME list. If they disagreed the plugin would preload a graph and then throw it away and rebuild — strictly worse than not preloading. So both now resolve `default` through one shared helper (stem_default_on, extracted from load_song), and a test rebuilds the WS's payload from load_song and requires the REST helper to produce the identical list, rather than pinning either against a snapshot. Also pinned: the mixdown is lifted OUT of the stem list (spec 5.3 — `full` is not a layer; listing it beside the instruments would play the whole song on top of the stems) while staying reachable as full_mix_url, a single-`full` pack keeps it as its only playable stem, and an unreadable pack yields an empty list rather than failing the request. Full suite 2608 passed. Consumed by feedBack-plugin-stems (preloadSong). * fix(song-info): call load_song for the stem payload — do not reimplement it CodeRabbit caught a real bug, and it would have hit most real libraries. load_song() falls back to the DEPRECATED `original_audio:` key when a pack has no reserved `full` stem — which is every pack written before feedpak 1.15.0. My payload rebuilt the full-mix rule from extract_meta and returned None for those: REST would say "no full mix" while the WS said there was one. Worse than a wrong field: the plugin would preload a graph WITHOUT the pristine mix and — because the stem signature still matched — never rebuild. Unity playback would silently downgrade to the lossy stem recombination. That is exactly the drift this PR claims to prevent, and my test had a hole: I only covered packs that carry a `full` stem. So stop reimplementing. The payload now calls load_song, whose LoadedSloppak already carries the partitioned stems and the resolved full mix, and builds the URLs exactly as ws_highway does. Drift is now impossible by construction rather than by agreement. extract_meta is reverted to its original shape (it never needed to change), and the shared stem_default_on helper stays as the one place `default: off` is resolved. Tests rewritten to compare against load_song — the WS's own function — for a reserved-`full` pack, a LEGACY original_audio pack (the case that was broken), and a single-`full` pack. Also documents the `?stems=1` contract in CHANGELOG.md. Full suite green.	2026-07-15 00:36:13 +02: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
Byron GamatosandGitHub	d876ded00f	fix(sloppak): bound the unpack cache; add read_member_bytes() so callers stop unpacking whole songs (#950) ... * fix(sloppak): bound the unpack cache, and add a way to read a song without unpacking it A tester's sloppak_cache reached 60 GB from an 1800-song library — his entire library, unpacked, none of it played. Stems are already-compressed audio, so an unpacked pack is ~1.1x its zip: the cache is a second, DECOMPRESSED copy of every song it touches. It had no size cap, no LRU, and no cleanup of any kind — not even when the song itself was deleted. Two halves: 1. resolve_source_dir() now evicts least-recently-used songs to stay under a cap (FEEDBACK_SLOPPAK_CACHE_MAX_MB, default 4 GB ≈ 130 songs of recency; 0 disables). The sweep runs on unpack — the only moment the cache grows — so it can't drift. An evicted song is dropped from _source_cache too: get_cached_source_dir() is the only thing media.py consults before falling back, so a stale path there would 404 every stem for the rest of the process instead of re-unpacking. get_cached_source_dir() now also verifies the dir still exists, which makes "just delete sloppak_cache/ to reclaim disk" safe advice. 2. read_member_bytes() reads ONE file out of a pack without unpacking it — the same trick read_cover_bytes() uses so the library grid doesn't explode every pack to show a cover. Unpacking a whole song to read a few KB of JSON is ~45x write amplification; doing it in a loop over the library is what produced the 60 GB. rig_builder's library-wide tone batch is the caller that did exactly that (fixed separately); this gives it, and everyone else, the right primitive. Eviction is concurrency-safe: unpacks run 2-at-a-time, so a dir being written is marked in-flight and the sweep skips it — checked and rmtree'd under one hold of the guard, and the marker is released even if the unpack raises (a leaked marker would make that dir permanently un-evictable). read_member_bytes normalizes both the requested path AND the archive's stored member names through safe_join, taking the last match — so './arrangements/x.json', backslash members from Windows tooling, and duplicate members that normalize to the same path all read back exactly as unpack-then-read did. Zip-slip is rejected before anything is opened. Tests: tests/test_sloppak_unpack_cache.py. All bite-tested (reverted each fix, watched it fail) — including one that was passing vacuously: a freshly-unpacked dir is the most-recently-used, so the LRU never reaches it and the in-flight race test proved nothing until the packs were sized to force the sweep that far. * test: split semicolon-joined statements (E702) CodeRabbit on #950. Style only; no behaviour change.	2026-07-13 17:13:08 +02:00
topkoaandClaude Opus 4.8	7cbf9824b1	Drop dead whisperx entry from allowed lyrics_source set ... The whisperx->transcribed alias runs before the membership check, so the literal whisperx never reaches _ALLOWED_LYRICS_SOURCES (same reason sng is omitted). Remove the dead entry. Per CodeRabbit review on #799. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: topkoa <topkoa@gmail.com>	2026-07-06 17:30:26 -04:00
topkoaandClaude Opus 4.8	33146cc7f6	Accept spec lyrics_source values (authored, transcribed) ... The feedpak spec (§7.1) defines the lyrics_source vocabulary as {authored, transcribed, user}, but the reader only accepted the legacy {xml, notechart, whisperx, user} set and silently downgraded anything else to "xml". A spec-compliant writer (e.g. the stem_splitter plugin, which emits transcribed for WhisperX-produced lyrics) therefore lost its provenance badge. Widen the allowed set to the union of the spec vocabulary and the legacy values so both validate, and alias the legacy whisperx engine name to the spec transcribed so existing packs normalise to the spec badge. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: topkoa <topkoa@gmail.com>	2026-07-06 17:24:26 -04:00
4 people	0a8c8945ea	v3 library: Albums view — the client half of the album-condense work (#716) ... * v3 library: Albums view — the client half of the album-condense work Follow-up to the query_albums endpoint: the UI that consumes it, plus the track-order plumbing the endpoint's track list needs. - Albums view (a fourth view toggle next to grid/tree/folder): album cards (cover / title / artist / track count) from /api/library/albums, respecting the active filter drawer; clicking one opens the track list with per-track play and a Play-album button that feeds the play queue (falls back to plain playSong when the queue plugin is absent). - Track order: the scanner now reads the feedpak `track`/`disc` fields (spec 1.12.0) into new nullable songs columns (idempotent ALTERs), and the album track list orders by the new `track` sort — disc, then track number, unauthored charts to the bottom by title. Charts without authored numbers keep working; they just sort alphabetically. - The albums view persists like the other view choices. 3 new tests: manifest track/disc extraction (and unauthored -> None), the disc->track->title sort order over /api/library, and the put() round-trip. Full-suite failure set matches the known env baseline (one tuner-config name swapped inside the suite-ordering flake family — the file passes 25/25 in isolation on clean main). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nm7tHs1Yvjjtnnu4nzJgdN * v3 albums: honour Genre/Match filters in album grid + detail (review fixes) The Albums view only partially respected the filter drawer: - /api/library/albums silently dropped the `genre` and `match` params the client sends via queryParams(), so with a Genre or Match filter active the album grid surfaced albums with zero matching tracks. Thread match_states/ genre through the endpoint -> query_albums -> _build_where, mirroring the /api/library grid route. (SmartCollection/pass-through providers keep their existing kwarg handling.) - The album-detail track list built its own params (provider/artist/album/ sort only), so it ignored ALL active filters — the track list and the Play-album queue could include songs the user had filtered out. Reuse queryParams({...}, {catalog: true}) so detail honours the same filters as the grid while pinning this album's artist/album and track order. +1 regression test (albums endpoint honours the Genre filter). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: byrongamatos <xasiklas@gmail.com>	2026-07-02 15:57:26 +02:00
4 people	80caf78306	v3 library: genre filter facet (reads feedpak genres) (#690) ... * feat(v3): genre filter facet (reads the feedpak genres field) Adds a Genre facet to the library Filters drawer, populated from each song's primary genre. Server: a genre column (idempotent ALTER, indexed) written from the sloppak manifest's genres list on scan (primary = genres[0]); a genre band in _build_where (OR within the selected set); GET /api/library/genres for the facet's distinct list. Client: a multi-select Genre section mirroring the tuning/mastery facets. Follows the merged spec 1.12.0 genres field (#40). v1 stores only the PRIMARY genre (genres[0]); secondary genres aren't filterable yet. Threaded like the mastery filter (separate query_page kwarg, so query_artists /query_stats are unaffected) -- genre filters the grid view. Needs a rescan to backfill genre on existing packs (only packs whose manifest carries genres). Verified live: a sloppak tagged genres:[Metal, Rock] -> /api/library/genres returns [Metal]; ?genre=Metal returns it; ?genre=Rock (secondary) returns none; a plain song stays ungenred. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QbexxfTt8q2tAn436MqGWF * fix(v3): scope genre facet to local provider (PR #690 review) The /api/library/genres facet always read the local meta DB, so a remote provider showed local genres while the `genre` filter was a no-op on that provider's grid. Make the endpoint provider-aware: return an empty facet for remote providers (kind != "local") and keep serving genres for the local library and its smart collections, which share the local DB. The v3 client now passes the active provider, mirroring the tuning-names facet. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: byrongamatos <xasiklas@gmail.com>	2026-07-02 13:58:05 +02:00
topkoa	7713ca92f4	Merge remote-tracking branch 'origin/main' into feat/feedpak-jsonc ... Signed-off-by: topkoa <topkoa@gmail.com> # Conflicts: # CHANGELOG.md	2026-07-01 03:27:38 -04:00
3 people	f3a5cb9ed3	feat(sloppak): expose full-mix original_audio alongside stems (#583) ... Lets a .sloppak ship the single pre-separation full mixdown next to its per-instrument stems, so the player can use the pristine original when nothing is isolated (demucs recombination is lossy) and switch to separated stems only when a slider drops below unity. - lib/sloppak.py::load_song parses the optional manifest `original_audio:` key into a new LoadedSloppak.original_audio field, with the same path-traversal guard + permissive "missing → disabled" posture as the drum_tab loader. - The highway WS song_info frame additively carries original_audio_url (served by the existing /api/sloppak/{filename}/file/{rel_path} endpoint, None for stems-only packs), has_original_audio, and has_stems. - A stem-less, full-mix-only sloppak now sets audio_url to the full mix (plays natively) instead of emitting audio_error. Message shape stays a stable contract — all additions are purely additive. Tests: tests/test_sloppak_original_audio_load.py (6 passing). Closes #580 Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 18:05:45 +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
4 people	32127bc70b	feat: save as .feedpak; discover and load both .feedpak and .sloppak (#553) ... * feat: save songs as .feedpak; discover and load both .feedpak and .sloppak The open song format was renamed sloppak -> feedpak (public spec lives in the feedback-feedpak-spec repo), but the server still wrote and recognized only `.sloppak`. The two are byte-identical on disk. Read both suffixes everywhere songs are discovered, uploaded, and loaded; writing the new `.feedpak` suffix is handled in the editor plugin repo. Keep the internal `format` tag `sloppak` so existing feature gates (stems, drums, keys) are untouched, matching the "internal rename not landed yet" stance. - lib/sloppak.py: add FEEDPAK_EXT / SLOPPAK_EXT / SONG_EXTS; is_sloppak() now matches either suffix (covers all 7 callers). - server.py: union scan glob over SONG_EXTS; widen loose-folder exclusion, settings DLC count, upload gate (_ALLOWED_SONG_EXTS) and zip-magic check; refresh user-facing messages to .feedpak. - static: library format filter relabeled Sloppak -> Feedpak (value stays sloppak, matches both); badge text SLOPPAK -> FEEDPAK in v2 + v3; filename-suffix detection and upload drag-drop filter accept both. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: topkoa <topkoa@gmail.com> * test: cover .feedpak/.sloppak dual-suffix support Add tests/test_feedpak_extension.py pinning the four paths PR #553 widened so a refactor can't drop .sloppak back-compat or stop accepting .feedpak: - is_sloppak / SONG_EXTS suffix detection (file + dir form, case-insensitive) - _background_scan discovery glob unions over both suffixes - POST /api/songs/upload accepts both, rejects wrong suffix + non-zip - save_settings DLC count includes both suffixes 19 tests, all passing; reuses the existing scan_module / TestClient / isolate_logging fixtures. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Signed-off-by: topkoa <topkoa@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: byrongamatos <xasiklas@gmail.com>	2026-06-22 20:47:56 +02:00
Bret Mogilefsky	b0338849f8	feat(core): read .jsonc data files (strip C-style comments) (feedpak-spec §8) ... feedpak-spec §8 (FEP #3 / PR #13) allows .jsonc files (JSON with C-style // line and /* */ block comments) anywhere .json is specified. A Reader MUST strip comments before parsing. Core's sloppak/feedpak readers parsed every side file with bare json.loads, so a .jsonc arrangement / notation / drum_tab / song_timeline / lyrics / keys would fail to load. - lib/jsonc.py (new): shared parse_jsonc(text) + load_json(path). String-aware regex (mirrors the spec reference validator in feedpak-spec/tools/validate.py) — keeps comment-like text inside JSON string literals. load_json auto-detects .jsonc by suffix; plain .json goes straight through json.loads. - lib/sloppak.py: import load_json; replace the 6 json.loads(...read_text...) side-file read sites (arrangement, notation, drum_tab, song_timeline, lyrics, keys) with load_json(<path>). Removed the now-unused `import json`. - scripts/lift_keys_notation.py: import load_json; replace the 3 read sites (song_timeline, arrangement beats fallback, arrangement lift). `import json` stays (json.dumps write at the notation sidecar emit). Additive (MINOR) change: older readers parse .jsonc as plain JSON and ignore comments via the spec's forward-compatibility rules, so no existing pack needs regeneration. Tests: tests/test_sloppak_jsonc_load.py (16 tests) — parse_jsonc unit cases (line/block/multiline/string-boundary/malformed/plain), and end-to-end loads for all 6 side-file types via .jsonc with comments, plus the lift helper reading .jsonc song_timeline + .jsonc arrangement beats, plus the string-boundary preservation rule through the full loader. 122 sloppak/lift tests pass.	2026-06-20 14:10:04 -07:00
3 people	b8382139ca	feat(core): adopt feedpak_version — read on load + stamp on manifest writes (spec §4) (#530) ... Core never read or emitted the manifest `feedpak_version` field. Adopt it: - sloppak.py: `FEEDPAK_VERSION = "1.2.0"` constant (the format version this build targets); `LoadedSloppak.feedpak_version` read from the manifest on load (string, else None for legacy/absent). - Stamp the version on the two core manifest-rewrite paths, without downgrading an existing (possibly higher) declared version: - gp2notation: `setdefault` before its notation-add rewrite. - songmeta: opportunistically when a metadata field is supplied (gated on the existing `dirty` flag, so never a standalone rewrite). Core has no create-from-scratch path (RS-free repo) — the editor plugin's create-mode save stamping FEEDPAK_VERSION is a follow-up in that repo. Internal "sloppak" naming is intentionally left as-is (a rename is out of scope / risky). Codex-reviewed: no P1/P2. +6 tests (read present/absent/non-string; metadata-write stamp-when-absent / preserve-existing / no-op-no-stamp) + updated the gp2notation key-order test for the appended version. 197 sloppak/songmeta/gp2notation tests pass. Closes #527. Part of got-feedback/feedback#334. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 21:59:04 +02:00
3 people	587fbbea81	feat(core): consume song_timeline tempos + time_signatures + per-chart tempos (feedpak 1.2.0) (#529) ... feedpak 1.2.0 added song-level `tempos` + `time_signatures` to song_timeline.json and a per-chart `tempos` override on arrangements (§6.10). Core stored the raw song_timeline dict but never consumed the maps, and didn't read per-chart tempos. - song.py: shared `sanitize_tempos([{time,bpm}])` (finite non-bool time, finite bpm>0, sorted); `Arrangement.tempos` field wired through arrangement_to_wire (omitted when None/empty per §6.10) / arrangement_from_wire. - sloppak.py: `_sanitize_time_signatures([{time,ts:[num,den]}])`; LoadedSloppak.tempos / .time_signatures, loaded from song_timeline.json INDEPENDENTLY of beats/sections (all are optional in 1.2.0). - server.py: stream `tempos` + `time_signatures` highway-WS messages; the active arrangement's per-chart `tempos` overrides the song-level map for that chart. Renderer/UI surfacing is a thin follow-up; this lands the data plumbing. Codex-reviewed: clean (no findings). +9 tests (sanitizers, per-chart wire round-trip + omit-when-absent, song-level load/sanitize/absent + maps-without- beats). 90 song/sloppak tests pass. (Pre-existing unrelated failure: test_diagnostics_redact, fails on clean main too.) Closes #526. Part of got-feedback/feedback#334. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 21:35:07 +02:00
3 people	e64378da78	feat(core): consume keys.json — song-level key/scale track (loader + WS) (#528) ... The feedpak spec defines keys.json (instrument-independent key/scale-change track, §7.7) but core never loaded it. Add it, mirroring the song_timeline / drum_tab side-file pattern: - lib/sloppak.py: LoadedSloppak gains a `keys` field; a permissive loader reads the manifest `keys:` key, path-safety-checks it, and stores a SANITIZED {version, events:[{t, key, scale?}]} — finite non-bool t (bad-t events dropped, not rewritten to 0), non-empty string key, optional string scale, sorted. Missing / unreadable / malformed -> None, never fatal. int-only version (a float/NaN version can't abort the load). - server.py: stream a `keys` highway-WS message when present + a `has_keys` song_info flag so a consumer can light up a key/scale display. Renderer/HUD surfacing is a thin follow-up; this lands the data plumbing so the highway, plugins, and the upcoming scale-degree (`sd`) annotation can read the active key/mode from the WS. Codex-reviewed (2 rounds: version-int-coercion + bad-t-drop hardening); clean. +7 loader tests (happy path, absent/permissive variants, sanitize/sort, non-int-version no-abort). 150 sloppak/load tests pass. Closes #525. Part of got-feedback/feedback#334. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 21:23:48 +02:00
3 people	21997f4b5c	Fix slow library cover loading: serve sloppak art without unpacking + revalidated caching (#534) ... * sloppak: read cover without unpacking + serialize/cap zip unpacks Album art for a zip-form sloppak was served by resolve_source_dir(), which unpacks the ENTIRE archive (stems included, ~30 MB) to disk just to read cover.jpg. On the library grid that meant a full extraction per card on scroll. - read_cover_bytes(): opens only the cover member from the zip (or reads the file for dir-form), with zip-slip guarding. ~4 ms vs a full unpack. - resolve_source_dir(): per-file lock + bounded global semaphore so concurrent callers don't rmtree + re-extract the same dest at once (a race), and a burst can't saturate disk/CPU. 8 concurrent calls now dedupe to 1 unpack. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * server: serve sloppak art via read_cover_bytes + cache album-art responses - get_song_art() sloppak branch now reads the cover directly (no full unpack), off-thread via asyncio.to_thread. - All art responses carry Cache-Control: public, max-age=86400. URLs are already cache-busted with ?v=<mtime>, so the browser stops re-fetching every cover on scroll-back; day bound self-heals any URL missing ?v. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * v3 library: lazy-load + async-decode card cover images The grid (24 cards/page) and artist-row thumbnails emitted plain <img> with no loading hint, so a whole page of covers fetched + decoded at once on each scroll batch. Add loading="lazy" decoding="async" to defer off-screen fetches and keep image decode off the main thread. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * address Codex review: zip cover normalization + correct art revalidation Findings from the preflight Codex passes: - sloppak.read_cover_bytes (zip form) read the raw manifest cover string via zf.read(), so a non-canonical name like './cover.jpg' or 'art/../cover.jpg' 404'd. Normalize via safe_join → relative member; reject escape and the degenerate root-collapse case ('.', 'subdir/..') like _unpack_zip does. - Album-art caching is correctness-first: Cache-Control: no-cache plus a strong validator, with real conditional handling (Starlette FileResponse emits an ETag but doesn't evaluate If-None-Match). All three art paths route through _art_conditional/_file_art_response → bodyless 304 on a matching validator. A long immutable max-age was rejected because the frontend ?v=<mtime> buster is only second-resolution and would pin a same-second rewrite. - The sloppak cover is validated by CONTENT (sha1 of the bytes), not a stat: a dir-form sloppak edited in place changes the cover file's mtime but not the directory's, so a dir-stat ETag could emit a stale 304. Content hashing is correct for both dir- and zip-form. get_song_art gained an optional request (internal get_art caller passes none — safe). Adds tests/test_sloppak_cover_art.py pinning read_cover_bytes (canonical, non-canonical, degenerate/escape, dir/zip, webp) and the endpoint's 304 contract incl. the dir-form in-place-edit no-stale-304 regression. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 00:22:43 +02:00
byrongamatosandClaude Opus 4.8	97a1e5fbf5	Fix two regressions in the terminology purge ... - diagnostics_redact: keep '.psarc' in the song-filename scrub regex. The purge swapped it for '.archive' (not a real extension), which would leak real .psarc filenames still on users' disks into diagnostic bundles. This is a redaction allow-list, not brand text. - sloppak: the legacy lyrics-source alias was a no-op ({"notechart": "notechart"}), so old manifests with lyrics_source=="sng" fell back to "xml" instead of migrating. Map {"sng": "notechart"} so the rename stays back-compatible. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-16 21:19:16 +02:00
Sin	4148b0e72e	Purge external-format terminology from code, tests and docs ... Reword comments/docstrings/strings and rename identifiers that referenced the external game and its file formats: - format-id "psarc" -> "archive"; local vars psarc_path -> song_path, psarc_base -> tone_base - lyrics provenance value "sng" -> "notechart" (legacy "sng" still accepted) - highway_3d fret-ghost scope value "rocksmith" -> "chords" (invalid/legacy values fall back to the default, preserving behaviour) - neutralise references in prose, test names/data, .gitattributes and docs No functional change beyond the renamed identifiers; all Python compiles.	2026-06-16 19:36:53 +01:00
byrongamatos	6c110398b4	Clean release snapshot	2026-06-16 18:47:13 +02:00