feat(editor): in-key highlight on the fretted lanes — capo-aware sounding pitch

[ChrisBeWithYou]

Roadmap 4.16a remainder (the guitar-lane scale-degree tint) — the top finer-detail slice from the queue plan, extending the merged #108 key/scale highlight from the piano roll to the fretted lanes.

What

• _soundingPitchPure: sounding pitch = open string + tuning offset + capo + fret, capo added exactly once. The fret convention (chart frets are capo-relative, fret 0 = the capo) is verified against core''s single source of the formula — lib/song.py pitch_from_base, which the tuner, open-string labels, and the highway''s scale-degree derivation all share.
• The double-count trap is pinned, not just avoided: _absolutePitch (string-moves) still deliberately omits capo — it compares two pitches on one arrangement, where the capo cancels — and both helpers now document the division of labor. A test asserts the difference between the two is exactly one capo.
• Render treatment mirrors the piano roll: out-of-key notes dim (body alpha cc→55, softened fret number) — never red, chromaticism isn''t an error (D20). Unresolvable pitches (unknown string, junk fret) stay fully lit rather than falsely flagged. The highlight context (open-string MIDI, normalized tuning, capo) is hoisted once per draw, so _drawNote does zero per-note arrangement work.
• The Key controls now show for any pitched arrangement (they were keys-mode-only); drum grid and Parts overview still hide them. Registry label and titles generalized.

Tests

tests/fret_key_highlight.test.js (8 cases): the formula against known pitches, Drop-D + capo composition, junk-input null guards, the omits-capo pin, and the decisive capo-flips-membership case — the same chart fret is out of key uncapoed and in key with capo 1, which an uncapoed resolver gets wrong. All fail on main.

Full JS suite green except tests/section_coverage.test.js, which fails on current main itself (pre-existing — looks like an _afterEdit/#107 squash-merge interaction; flagging separately).

🤖 Generated with Claude Code

https://claude.ai/code/session_01JEoFeTPSnz4NpwwCG52hnu

Summary by CodeRabbit

• New Features
  • Expanded in-key highlighting to apply consistently across pitched arrangement views (not just piano roll).
  • Key-highlight controls are now available for pitched arrangements while remaining hidden for drum grid and parts overview modes.
• Bug Fixes
  • Notes outside the current key now dim (instead of turning red); unresolvable pitches remain fully lit.
  • Improved capo handling to prevent incorrect in-key/out-of-key highlighting.
• Documentation
  • Updated changelog and the “In-key” tooltip to reflect the new dimming behavior.
• Tests
  • Added automated coverage for capo and out-of-key highlighting behavior.

[coderabbitai]

Warning

Review limit reached

@byrongamatos, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 28 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71f5b058-198b-4eb8-aa71-6dcc80ae3902

📥 Commits

Reviewing files that changed from the base of the PR and between 856442e and b6e0aa7.

📒 Files selected for processing (3)

• CHANGELOG.md
• screen.html
• screen.js

📝 Walkthrough

Walkthrough

Adds capo-aware sounding pitch computation for fretted lanes, broadens key-highlight visibility beyond piano roll, changes out-of-key notes to dim instead of redden, adds a Node test suite, and updates changelog and tooltip text.

Changes

In-key highlight for fretted lanes

Layer / File(s)	Summary
Capo-aware pitch helpers screen.js	_absolutePitch now omits capo and _soundingPitchPure computes sounding MIDI from open MIDI + tuning + capo + fret, applying capo once and returning null for invalid inputs.
Highlight computation and note rendering screen.js	Key-highlight controls now show for any pitched arrangement except drum edit and Parts overview; per-draw highlight state is hoisted, _drawNote uses sounding pitch for out-of-key detection, and out-of-key notes dim.
Capo/key membership test suite tests/fret_key_highlight.test.js	New Node tests extract pure pitch/scale logic from screen.js and verify capo handling, invalid-input handling, absolute-vs-sounding pitch separation, and capo-driven membership flips.
Documentation and tooltip updates CHANGELOG.md, screen.html	Changelog and In-key tooltip text are updated to describe the new fretted-lane highlight behavior and dimming wording.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant DrawLoop as Draw
  participant Highlight as ghl
  participant DrawNote as _drawNote
  participant Pitch as _soundingPitchPure
  DrawLoop->>Highlight: compute active key highlight once per draw
  DrawLoop->>DrawNote: draw note with ghl context
  DrawNote->>Pitch: compute sounding pitch tuning+capo+fret
  Pitch-->>DrawNote: sounding MIDI or null
  DrawNote-->>DrawLoop: render dimmed or lit note

Loading

Possibly related PRs

• got-feedBack/feedBack-plugin-editor#108: Updates the same in-key highlight and pitch-membership path in screen.js, including the capo-aware sounding pitch logic this PR extends.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: in-key highlighting for fretted lanes with capo-aware sounding pitch.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/editor-key-highlight-guitar

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

tests/fret_key_highlight.test.js (1)

35-45: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Brace-counting extraction is fragile but low-risk for now.

extractFn counts braces to find the end of _absolutePitch; this would break silently (or extract too little/too much) if the function body ever contained a {/} inside a string, regex, or comment. Given the function is small and stable, this is a minor concern — worth a comment noting the assumption, or eventually exporting the pure functions from screen.js directly for test isolation instead of parsing source text.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/fret_key_highlight.test.js` around lines 35 - 45, The source-text brace
counting in extractFn is brittle because it assumes _absolutePitch and other
functions in screen.js never contain braces in strings, regexes, or comments.
Update the test helper to either add a clear assumption comment near extractFn
or, preferably, stop parsing source text by exporting the pure functions from
screen.js and importing them directly in tests. Keep the change localized to
extractFn and the related screen.js exports.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@tests/fret_key_highlight.test.js`:
- Around line 35-45: The source-text brace counting in extractFn is brittle
because it assumes _absolutePitch and other functions in screen.js never contain
braces in strings, regexes, or comments. Update the test helper to either add a
clear assumption comment near extractFn or, preferably, stop parsing source text
by exporting the pure functions from screen.js and importing them directly in
tests. Keep the change localized to extractFn and the related screen.js exports.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: fbc6f718-c425-4bb7-92ad-ed0325a1da13

📥 Commits

Reviewing files that changed from the base of the PR and between 2222c59 and 549521c.

📒 Files selected for processing (4)

• CHANGELOG.md
• screen.html
• screen.js
• tests/fret_key_highlight.test.js

[byrongamatos]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.