Ω-W1-T5 review fixes: unify the drag frame resolve onto frameToX/xToFrame; honest comments on grabbableMarks and the grey-loop-mark contrast trade

src/core/instrument/ui/waveform_view.cpp

@@ -4,7 +4,6 @@
 
 #include <algorithm>
 #include <cstddef>
-#include <cstdlib>  // std::abs (int overload)
 
 #include "core/instrument/ui/sample_bands.h"  // waveformLanes (the band's lane inventory)
 #include "core/ui/component_geometry.h"       // waveformColumnCount (THE draw chain's columns)
@@ -170,13 +169,13 @@ std::int64_t resolveDragFrame(const OverlayArea& area, std::int64_t frameCount,
     if (dxPixels == 0) return start;
     const int w = std::max(0, area.rect.width);
     if (frameCount <= 0 || w <= 0) return start;  // no room to move
-    // Proportional shift, rounded to the nearest frame (same linear map as frameToX/xToFrame).
-    const std::int64_t magnitude =
-        (static_cast<std::int64_t>(std::abs(dxPixels)) * frameCount +
-         static_cast<std::int64_t>(w) / 2) /
-        static_cast<std::int64_t>(w);
-    const std::int64_t shift = dxPixels > 0 ? magnitude : -magnitude;
-    return clampFrame(start + shift, frameCount);
+    // THE unified mapping, not a second one: find the start frame's own column (frameToX),
+    // walk it by dxPixels, and read the frame back off the resulting pixel (xToFrame) — so a
+    // drag always resolves to the column under the cursor, never a proportional approximation
+    // of it. A prior independent linear map here could disagree with frameToX/xToFrame's
+    // truncating column partition, most visibly when frames < columns.
+    const int grabX = frameToX(area, frameCount, start);
+    return xToFrame(area, frameCount, grabX + dxPixels);
 }
 
 std::int64_t nearestZeroCrossing(const AudioSample* pcm, std::int64_t frames,

src/core/instrument/ui/waveform_view.h

@@ -83,6 +83,14 @@ inline constexpr int kMarkerGrabWidth = 5;
 // for every f whenever frames <= columns, i.e. exactly where the choice of end is observable).
 // Above that, several frames share a column and the round trip snaps to the column's first
 // frame, which is the quantization the shared column already is.
+//
+// KNOWN CONVENTION MISMATCH, not a bug: in the frames < columns regime a mark lands on the
+// LAST column of its frame's span (above), while the spline contour and the staged AHD
+// polyline map normalized t in [0,1] straight across the same box and so land on a span's
+// FIRST column instead. Both land inside the frame's own span, so the mapping contract holds,
+// but the two conventions can disagree by up to a span's width for captures under ~1000
+// frames. Unifying them is a real option, left alone here since it touches the spline/AHD draw
+// path rather than this pair.
 
 // x pixel of `frame`: the column that draws it. `frameCount` itself is a span's EXCLUSIVE end,
 // not a frame, and maps to area.right(). Frame is clamped to [0, frameCount] first;
@@ -169,9 +177,11 @@ int crossfadeWedgeHeight(int x0, int x1, int x);
 int markerAtPoint(const OverlayArea& area, std::int64_t frameCount, const std::int64_t* frames,
                   int count, int x, int y);
 
-// Resolves a drag to a new frame: `startFrame` shifted by round(dxPixels * frameCount /
-// areaWidth), clamped to [0, frameCount]. The shell applies between-marker clamps (e.g.
-// start <= loopEnd) after this per-marker resolve.
+// Resolves a drag to a new frame: locates `startFrame`'s own column via frameToX, walks it by
+// dxPixels, and reads the frame back via xToFrame — the SAME partition, so the result is always
+// the frame the cursor's column actually draws, never a proportional approximation of it.
+// Clamped to [0, frameCount]. The shell applies between-marker clamps (e.g. start <= loopEnd)
+// after this per-marker resolve.
 std::int64_t resolveDragFrame(const OverlayArea& area, std::int64_t frameCount,
                               std::int64_t startFrame, int dxPixels);