feat(v3): flag library songs by working-tuning match (working-tuning PR 6)#668
Merged
Conversation
…PR 6) Each song's tuning chip in the v3 library grid is now coloured by whether your CURRENT working tuning covers it: green = play it now, amber = needs a retune (with a matching tooltip). Uses the tuner plugin's coverageReport (async), so it runs as a post-paint decoration pass — chips render instantly, then colour a tick later; a token cancels a superseded pass so scrolling stays snappy. Re-flags on working-tuning-changed (retune / instrument swap / reset), no re-fetch. Fully feature-detected: without the tuner coverage API + the host workingTuning state, the chips render exactly as before. v3-only, single file (static/v3/songs.js). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QbexxfTt8q2tAn436MqGWF
…668 review) Review fixes for working-tuning PR 6 (library tuning-match chips): - Bass songs were scored against the guitar tuning. The chip passed no arrangement to coverageReport, so isBassArrangement fell back to guitar — a 4-string bass drop-D read as guitar could FALSE-MATCH a drop-D guitar player (green). songCard now flags a bass-only song (every arrangement name matches /\bbass\b/) with data-tuning-bass, and decorateTuningChips passes arrangement 'Bass'/'Lead' so coverage uses the right base pitches. Mixed guitar+bass songs → guitar (the song-level tuning is the guitar one); least-wrong given one tuning per song. - Per-chip /api/settings fetch storm. coverageReport()→_playerTuning() fetched /api/settings once per visible chip per grid paint (~60). _playerTuning is now memoized (the player's tuning is song-independent) so all callers share one read; invalidated on instrument:changed / working-tuning-changed, with a 3s TTL so a settings write that doesn't emit an event still heals. A transient fetch failure is NOT cached (next read retries) — else one hiccup would freeze coverage. Tests: player tuning shared across songs (one fetch); transient-failure retry (fails without the fix). The prior #680 dedup test updated for the memoized behavior. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
byrongamatos
force-pushed
the
feat/v3-library-tuning-match
branch
from
July 1, 2026 08:51
f3dbaa3 to
55e1e59
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Working-tuning PR 6 (Phase D — library / song-picker consumer). Based on
main; feature-detects the tuner'scoverageReport+ the hostworkingTuning(from #657/#660 + #658), so it merges independently and lights up once those land.What
Each song's existing tuning chip in the v3 library grid is coloured by whether your current working tuning covers it — so you can see at a glance what you can play right now vs. what needs a retune.
How
decorateTuningChips):songCardtags each chip withdata-tuning-offsets; after the (sync) window paints, an async pass calls the tuner plugin'scoverageReport(songInfo)per visible chip and appliesbg-emerald-500/bg-amber-400. A token cancels a superseded pass (re-paint / tuning change) so scrolling stays snappy.working-tuning-changed— re-colours in place, no re-fetch or re-paint.window._tunerAutoOpen.coverageReport+window.feedBack.workingTuning, the chips render exactly as today.The companion half — "on picking a mismatched song, prompt retune/switch" — is already the #666 gate (opening a mismatched song auto-opens the tuner and holds playback). This PR is the passive flagging that pairs with it.
v3-only; single file (
static/v3/songs.js).Test
Verified headless (Chrome via playwright-core) against the real library — 8/8: chip neutral before the capability; a matching tuning → green (+ "matches your tuning"); a mismatched tuning → amber (+ "needs a retune"); re-flags to green on the event; all 14 visible chips decorate; zero console errors.
Note
Touches
songs.js, which in-flight library PRs also touch (A-Z rail #653, favorites #654) — different regions, so a clean merge is expected.🤖 Generated with Claude Code
https://claude.ai/code/session_01QbexxfTt8q2tAn436MqGWF