Repository navigation
fix(capo): read capo charts' fretted notes from the nut - #74
Closed
mattromano wants to merge 1 commit into
Closed
mattromano wants to merge 1 commit into
mattromano wants to merge 1 commit into
Conversation
Rocksmith capo charts write fretted notes at their absolute fret and only fret 0 means open (sounding at the capo): a capo-4 E chord is A7 D6 G0 B5. Expected pitch added the capo to every fret, so each fretted note was expected `capo` semitones sharp and capo charts barely scored. Expected pitch is now open + fret for fretted notes and open + capo for open ones. The display fallback reports frets from the nut too. The desktop engine applies open + capo + fret itself, so both bridge funnels hand it capo 0 with open notes moved to the capo fret. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mattromano <42412983+mattromano@users.noreply.github.com>
Contributor
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 46 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This was referenced Oct 10, 2026
Author
|
Consolidated into #84 (commits kept, rebased onto main, plus the review fixes). |
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
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.
What
Closes #73
Capo charts follow the Rocksmith convention: a fretted note's fret counts from the nut, and fret 0 means open, which sounds at the capo. A capo-4 E chord is
A7 D6 G0 B5. Note detection added the capo to every fret, so each fretted note was expectedcaposemitones sharp and capo charts barely scored._ndMidiFromStringFretnow usesopen + fretfor fretted notes andopen + capofor open ones, through a new helper_ndAbsoluteFret. Every expected-pitch, band-range and chord-member calculation already goes through this function, so this one change covers them all._ndMidiToStringFretis the display fallback for noodling between chart notes. It now reports the fret counted from the nut, so it matches how the chart writes it.open + capo + fretitself, and there's no option to change that. Both bridge funnels (_ndBridgeSetChart,_ndBridgeScoreChord) now pass the enginecapo: 0and move open notes to the capo fret (_ndEngineCapoPayload), so the engine expects the same pitches as the JS path. This also covers the contained chart andsetVerifyTargetscoring. A verify context that passestuning+caponow uses the chart convention, which_ndSanitizeVerifyCtxalready called "the chart convention". TheopenMidispath still forces capo 0, so it's unchanged.Version bumped 1.32.0 → 1.33.0 in
plugin.json,package.jsonand_ND_VERSION. This collides with #72, which bumps to the same version. Whichever merges second needs a one-line re-bump.Related: #72 (effective tuning /
getCapo()). That PR changes wherecapocomes from, and this one changes how it's applied, so they don't depend on each other. If both land, a chart-transformcapogoes through the same mapping. Both PRs edit the two bridge funnels on adjacent lines, so expect a small textual conflict there.Not in this PR: core has the same
base + offset + capo + fretformula inlib/song.py(pitch_from_base/note_pitch_midi). The highway's scale-degree fill inlib/routers/ws_highway.pyuses it. That's a core change and worth its own issue.Tests
test/capo_expected_pitch.test.js(6 tests):A7 D6 G0 B5maps to E3 G#3 B3 E4, and the open low E maps to G#2_ndEngineCapoPayloadrewrites only open notes, keeps technique flags, and returns a capo-0 payload unchangedsetChartreceivescapo: 0andG0 → G4test/verify-target-context.test.js: the IPC assertion now expects the capo folded into the frets (capo: 0, a fretted target keeps its fret) instead ofcapo: 2being passed through.npm test: 359/359 pass.node --check screen.jsis OK, andfeedBack-plugin-spec/tools/validate.pyreportsok.queue_set_summary.test.js› "last-song Exit retires the log…" fails intermittently in the full run on unmodifiedmainand passes on its own. It passed in this branch's final run.Checklist
version_sync.test.jsgreen)git commit -s)🤖 Generated with Claude Code