Trimming a loop boundary means retyping nine characters

[thcp]

What goes wrong

The two loop bound fields in the footer accept an exact time, which is the right idea, but the only way to change one is to type it. A loop is almost never chosen exactly on the first try: you drag a rough region, play it, and then want the start 40 milliseconds earlier because it clips the transient.

Doing that today means clicking into the field, selecting 00:12.480, and typing 00:12.440. Nine characters to move one number. It is slower than dragging the region again and less precise, so the fields end up unused for the one job they are best at.

Who it affects

Anyone setting a loop for practice, which is the feature's whole purpose. The drag is good for choosing the bar; nothing is good for the last few tens of milliseconds.

What a fix has to handle

• Two different magnitudes. Seconds and milliseconds are both wanted, and a control that only offers one is only half useful
• A step size that is worth a notch. One millisecond per scroll needs a hundred notches to cover something audible
• The existing bounds rules: clamp to the track, never let the two cross inside the minimum loop length
• Not fighting the wheel handlers already on the page. The lanes zoom on wheel (Zoom the waveform lanes with the wheel, without changing what they look like #493) and the page scrolls
• Discoverability. A field that responds to the wheel looks identical to one that does not, and the two units are not guessable at all

[thcp]

Fixed in 0.16.1, which is now on main via #541.

The wheel adjusts both loop bounds now. Left of the decimal point moves seconds, a tenth of a second per notch. Right of it moves milliseconds, a hundredth per notch. One millisecond per notch would need a hundred notches to cover something you can hear.

Two things that shaped the implementation.

Character-level hit-testing inside an <input> is not reliable across browsers, since caretRangeFromPoint hands back the element rather than an offset inside it. Only the decimal point matters here, so the text up to it is measured and compared against the pointer.

A nudge past either end of the track, or one that would squeeze the loop under the minimum length, is dropped rather than clamped. Clamping meant holding the wheel at the end of a track quietly dragged the other bound along.

The fields take an ns-resize cursor so they look adjustable, and a label above them says what the wheel does, because a field that responds to the wheel looks identical to one that does not.

Landed in #547. No automated coverage yet: it is a DOM-level behaviour that needs a Playwright spec.