feat(keys_highway_3d): key layout modes, lane-color opacity & octave lines#803
Conversation
… lines Add a Highway layout section to the settings with a rebuilt way to draw sharps/flats and lanes on the 3D piano highway: - Sharps & flats layout (keys3d_bg_sharpMode): floating (original raised plane), flat (one plane, zero-overlap piano-shaped tiled lanes with the naturals evened out), and realistic (one plane, bars sized like the physical keys). All geometry lives in pure laneSpanFlat()/laneSpanReal() helpers. Default: realistic. - Lane color opacity (keys3d_bg_laneOpacity, 0-1): fades the pitch-class lane tint; at 0 it is a dark floor with guide lines only at the key-block boundaries (E-F and each octave), toward 1 full vivid colored lanes. The strips, per-lane separators and block lines crossfade with the value. Default: 0. - Octave separators (keys3d_bg_octaveGaps, default on) and Octave line contrast (keys3d_bg_octaveContrast, 0-1): the B->C octave line is a dark layer scaled by lane opacity plus a bright layer scaled by its inverse, so it auto-shifts dark->bright as the lanes fade. Settings re-read on init() so they apply on the next chart build. All other behavior (MIDI scoring, palettes, camera, themes, hit feedback) is unchanged. Unit tests cover the new defaults, the sharp-mode setting, and the lane geometry (tiling/evening for flat, uniform/overlap for realistic). Signed-off-by: LegionaryLeader <legionaryleader@gmail.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughAdds sharp/flat highway layout modes to ChangesHighway Layout Feature
Estimated code review effort: 3 (Moderate) | ~30 minutes Sequence Diagram(s)sequenceDiagram
participant SettingsUI
participant window.keys3dSetSharpMode
participant localStorage
participant ScreenInstance
SettingsUI->>window.keys3dSetSharpMode: select mode
window.keys3dSetSharpMode->>localStorage: persist keys3d_bg_sharpMode
window.keys3dSetSharpMode->>ScreenInstance: dispatch keys3d:settings
ScreenInstance->>ScreenInstance: update _sharpMode
sequenceDiagram
participant ScreenInstance
participant buildKeyboardAndHighway
participant buildNoteMeshes
participant laneSpanFor
ScreenInstance->>buildKeyboardAndHighway: build lane guides
buildKeyboardAndHighway->>laneSpanFor: resolve lane geometry
ScreenInstance->>buildNoteMeshes: build note bars
buildNoteMeshes->>laneSpanFor: place notes by sharp mode
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In `@plugins/keys_highway_3d/screen.js`:
- Around line 1318-1331: Update the sharp-mode default description in
readSharpModeSetting() to match the actual fallback value. The comment near
FX_LS_SHARPMODE and SHARP_MODES still says 'floating' is the default, but the
function returns 'realistic' when no setting is stored. Keep the documentation
and return value consistent by revising the stale comment text around
readSharpModeSetting().
In `@plugins/keys_highway_3d/settings.html`:
- Around line 308-310: Update the stale inline comment near hydrateFxBool in
settings.html so it matches the actual octaveGaps default state used by Keys
Highway 3D. The comment currently says octaveGaps defaults OFF, but the relevant
symbols FX_DEFAULTS.octaveGaps in screen.js and the keysh3d-fx-octavegaps
checkbox are both initialized as ON/checked by default. Keep the hydration call
unchanged and only correct the comment wording to avoid misleading maintainers.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 30f87574-e273-4b28-a8de-6245ef321cbc
📒 Files selected for processing (5)
plugins/keys_highway_3d/README.mdplugins/keys_highway_3d/plugin.jsonplugins/keys_highway_3d/screen.jsplugins/keys_highway_3d/settings.htmlplugins/keys_highway_3d/tests/fx_settings.test.js
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…hbor sharp is out of range laneSpanFlat() trimmed a white key's edge for its neighboring black key's lane even when that neighbor midi fell outside range.activeLow..range.activeHigh — the neighbor's lane is never drawn (see the activeLow/activeHigh skip around the lane-strip loop), so the trim left a dark, unfilled sliver at the active-range boundary with no sharp lane to fill it. Gate the trim on the neighbor being in-range; callers that don't pass a range (e.g. the raw-tiling unit tests) keep the prior unconditional-trim behavior. Also add the CHANGELOG entry for this PR's feature set, following the existing keys_highway_3d wording convention (no plugin-local CHANGELOG exists; plugin.json was already bumped 0.1.2 -> 0.2.0 by the original commits). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Lane Opacity Slider
A new slider that affects the overall opacity of whatever color palette a user has selected
0% means no color, dark gray background for a clean look
100% is full vivid color
The current amount default will be set to 0%
The Opacity Slider is paired with another setting to automatically change its color to match:
The Octave Separator
This checkbox setting allows the user to add a little bit of visual clarity to their game by making the space between Lanes at all octave (B-C) a little wider, allowing your eyes to break the piano up into sections or blocks more easily
The default of this setting will be on
Highway Layouts
There are now 3 layouts available for users depending on how a player wants to see the piano
The original "Floating" - sharps & flats are physically higher than the naturals
"Non-floating" - sharps & flats are placed on the same height plane as the other keys
"Realistic Key Sizes" - Changes the note gems all to be a more realistic size, works best with colors off for the lane background
The default layout will be Realistic Key Sizes
Summary by CodeRabbit
New Features
Bug Fixes
Documentation / Chores