Open-string notes render at camera-center instead of their neck position (highway_3d + legacy highway)

[carochacs]

Open-string notes appear at a seemingly random spot instead of lining up with the fretted notes around them.

Root cause

Not a parser/timing bug — lib/gp2rs_gpx.py and lib/gp2rs.py compute one timestamp per beat and apply it to every note in the beat identically, fretted or open (lib/gp2rs_gpx.py:1826, lib/gp2rs.py:837-839). Times are correct.

The mispositioning is in the renderers' X-axis placement:

• 3D highway — plugins/highway_3d/screen.js:14337:

  const xBase = n.f === 0 ? (openX !== undefined ? openX : curX) : xFretMid(n.f);

  A standalone open note has no openX, so it falls back to curX — wherever the camera currently happens to be centered, which is driven entirely by the other (fretted) notes nearby. Open strings (fret 0) are explicitly excluded from the camera-anchor computation (lib/gp2rs_gpx.py:2057-2074, lib/gp2rs.py:1097-1118 — "Exclude open strings (fret 0) — they span the full highway and shouldn't cause the fret range to shift"), so an open note's on-screen position is disconnected from the neck position of the phrase around it.
• Legacy 2D highway — static/js/highway-draw.js:100-121: the caller does compute a real nut-position x = fretX(hwState, n.f, p.scale, W) (static/js/highway-draw.js:533), but drawNote() discards it for fret === 0 && !isChord and instead centers the bar at W/2 (screen center) regardless of the surrounding notes' fret position.

This "open string = wide bar" rendering is intentional, but the current fallback (camera-center / screen-center) makes it look randomly placed relative to the rest of the phrase.

Suggested fix

Interpolate openX from neighboring fretted-note positions in time (rather than falling back to camera-center / screen-center) in both plugins/highway_3d/screen.js:14337 and static/js/highway-draw.js:100-121, so a standalone open note visually belongs with the phrase around it.

Notes

No existing test/commit treats this as a bug (git log --oneline --all | grep -iE "open.string" — no hits). Flagging as a design gap, not a regression.

[raphaelmorrissy]

I can work on this. Before changing both renderers, I'd like to make the visual rule explicit so the 2D and 3D highways cannot drift.

Proposed contract for a standalone open-string note:

1. Keep the intentional wide open-string bar; only its X center changes.
2. Build neck-context samples from nearby rendered events that contain at least one fretted note (standalone notes and chords). For a chord, use the midpoint of its non-zero fret span.
3. Search within the open note's active anchor interval:
   • previous + next sample: linearly interpolate their X positions by event time;
   • only one sample: reuse that sample's X position;
   • no sample: use the center of the active anchor lane;
   • no usable anchor either: retain the current renderer fallback.
4. Apply the same policy to the effective/filtered chart in both the legacy 2D and 3D highways. This is rendering-only: no import data, timing, anchors, camera targeting, or grading behavior changes.
5. Pin the behavior with shared cases for: two-sided interpolation, previous-only, next-only, anchor fallback, and no-context fallback in both renderers.

This would make the behavior deterministic and documentable without letting a note in a different anchor/neck region influence the open note. Does this contract match the intended UX? If so, I'll implement it and add the rule to the changelog/tests.