Stash/stash-ios

Fork 0

M2-03: Seek from the transcript #30

New issue

Closed

opened 2026-08-08 19:56:51 -04:00 by agent · 1 comment

agent commented

2026-08-08 19:56:51 -04:00

Member

Tap a cue and playback jumps there. The cue under the playhead highlights as the memo plays.

Why

This is the payoff for every timestamp M1 spent effort getting right — the cue boundaries, the
millisecond rounding, the seam continuity across part boundaries. A forty-minute walk memo is not
navigable by scrubbing blind; it is navigable by reading down the transcript and tapping the part
worth hearing.

M2-01 (#27) notes this explicitly: "Tapping a cue does not seek anything, because nothing plays a
memo yet. If playback ever lands, the timestamps are already there to hang it on." This is that.

Depends on

#27 (M2-01) for the parsed cues, and M2-02 for the transport.

Scope

Tapping a cue seeks playback to that cue's start.
The cue containing the playhead is visually current, and the list follows it as playback runs.
Following can be interrupted by scrolling and resumed, rather than yanking the view back while
somebody is reading ahead.

The alignment question this finally answers

"Whether cue times match the words by ear" has been open since #8 and #9 and no test has closed
it. This issue makes the misalignment visible: tap a cue, and either the words start or they do
not. Worth measuring on a real walk memo rather than a short test recording — drift, if there is
any, accumulates.

If cue times turn out to be systematically off, that is a finding for a separate issue against
transcription, not something to correct with an offset here.

Done when

Tapping a cue in a forty-minute memo starts playback at those words.
The current cue is obvious while playing.
Scrolling away from the playhead does not fight the user.

Milestone 2 of the Stash v3 rebuild. M2 is still app-side — no sync, no account, no server. It
turns a list of memos into something you can open, listen to, read and see the route of. Sync
arrives in M3. There is no milestone/M2 label yet (creating org labels needs owner rights), so
the title carries the milestone.

Working agreement for every issue in this repo: feature branch, tested before the PR opens
(on-device where the label says so), then Wes reviews the PR and we walk the code together. Docs
update in the same commit. A PR that takes more than 20 minutes to review is too big — say so and
split it.

Tap a cue and playback jumps there. The cue under the playhead highlights as the memo plays. ## Why This is the payoff for every timestamp M1 spent effort getting right — the cue boundaries, the millisecond rounding, the seam continuity across part boundaries. A forty-minute walk memo is not navigable by scrubbing blind; it is navigable by reading down the transcript and tapping the part worth hearing. M2-01 (#27) notes this explicitly: *"Tapping a cue does not seek anything, because nothing plays a memo yet. If playback ever lands, the timestamps are already there to hang it on."* This is that. ## Depends on #27 (M2-01) for the parsed cues, and M2-02 for the transport. ## Scope - Tapping a cue seeks playback to that cue's start. - The cue containing the playhead is visually current, and the list follows it as playback runs. - Following can be interrupted by scrolling and resumed, rather than yanking the view back while somebody is reading ahead. ## The alignment question this finally answers *"Whether cue times match the words by ear"* has been open since #8 and #9 and no test has closed it. This issue makes the misalignment visible: tap a cue, and either the words start or they do not. Worth measuring on a real walk memo rather than a short test recording — drift, if there is any, accumulates. If cue times turn out to be systematically off, that is a finding for a separate issue against transcription, not something to correct with an offset here. ## Done when - [ ] Tapping a cue in a forty-minute memo starts playback at those words. - [ ] The current cue is obvious while playing. - [ ] Scrolling away from the playhead does not fight the user. --- *Milestone 2 of the Stash v3 rebuild. M2 is still app-side — **no sync, no account, no server**. It turns a list of memos into something you can open, listen to, read and see the route of. Sync arrives in M3. There is no `milestone/M2` label yet (creating org labels needs owner rights), so the title carries the milestone.* *Working agreement for every issue in this repo: feature branch, tested before the PR opens (on-device where the label says so), then Wes reviews the PR and we walk the code together. Docs update in the same commit. A PR that takes more than 20 minutes to review is too big — say so and split it.*

agent added the

labels

2026-08-08 19:56:51 -04:00

agent referenced this issue from a commit

2026-08-09 16:05:29 -04:00

M2-03: seek from the transcript

agent referenced this issue from a pull request that will close it,

2026-08-09 16:06:15 -04:00

M2-03: Seek from the transcript #44

agent commented

2026-08-09 16:06:55 -04:00

Author

Member

PR: #44

The alignment question this issue was going to answer is answered. On a one-hour memo, seeking
from cues near the end put the audio within about half a second of the words. Nothing was
systematically off, so there is no follow-up issue against transcription — the cue times the
recogniser emits hold up over an hour, and whatever drift exists does not accumulate to anything
audible.

One thing in the issue's scope was traded away. Cue rows are buttons now, and a button consumes
the long press that starts a text selection — measured on the device, not assumed. M2-01 had made
cue text selectable so a line could be copied out; both cannot have the gesture. Playing from a
tapped cue is what every timestamp in the transcript was built for, so it won, and the modifier was
removed rather than left in place doing nothing. Wes, testing it: "I can't click and copy a line,
but I honestly don't really need that feature." If copying a line ever needs to come back, a
long-press menu on the row is the way, and that is a separate decision.

Done-when, against the device pass:

Tapping a cue starts playback at those words — verified on a one-hour memo.
The current cue is obvious while playing.
Scrolling away from the playhead does not fight the user: following stops on the first
interaction and only comes back when asked, by the button above the transport or by tapping a
cue.

Not verified anywhere: two windows; and the three bugs the Codex reviews found — a tap dropped
while the file was still opening, a capture failing to cancel a pending tap, and a request suspended
across a capture that starts and fails — are fixed by inspection, with unit tests only on the pure
rules underneath them. The simulator could not be driven at all: this machine cannot post clicks
into it, the same limitation recorded in M1-11.

A decision file went to stash-docs: Stash/stash-docs#6 — note on that PR
that it carries five earlier decision files that were never pushed to that repository's main.

PR: https://git.wes.today/Stash/stash-ios/pulls/44 **The alignment question this issue was going to answer is answered.** On a one-hour memo, seeking from cues near the end put the audio within about half a second of the words. Nothing was systematically off, so there is no follow-up issue against transcription — the cue times the recogniser emits hold up over an hour, and whatever drift exists does not accumulate to anything audible. **One thing in the issue's scope was traded away.** Cue rows are buttons now, and a button consumes the long press that starts a text selection — measured on the device, not assumed. M2-01 had made cue text selectable so a line could be copied out; both cannot have the gesture. Playing from a tapped cue is what every timestamp in the transcript was built for, so it won, and the modifier was removed rather than left in place doing nothing. Wes, testing it: *"I can't click and copy a line, but I honestly don't really need that feature."* If copying a line ever needs to come back, a long-press menu on the row is the way, and that is a separate decision. Done-when, against the device pass: - [x] Tapping a cue starts playback at those words — verified on a one-hour memo. - [x] The current cue is obvious while playing. - [x] Scrolling away from the playhead does not fight the user: following stops on the first interaction and only comes back when asked, by the button above the transport or by tapping a cue. **Not verified anywhere:** two windows; and the three bugs the Codex reviews found — a tap dropped while the file was still opening, a capture failing to cancel a pending tap, and a request suspended across a capture that starts and fails — are fixed by inspection, with unit tests only on the pure rules underneath them. The simulator could not be driven at all: this machine cannot post clicks into it, the same limitation recorded in M1-11. A decision file went to stash-docs: https://git.wes.today/Stash/stash-docs/pulls/6 — note on that PR that it carries five earlier decision files that were never pushed to that repository's `main`.

wk closed this issue

2026-08-09 16:09:36 -04:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Stash/stash-ios#30

No description provided.

Rows
Columns