Markers and the edit

Reading the script is what produces the marker list. Nothing is logged by hand, nothing is remembered afterwards, and by the time you stop recording the rough edit has already described itself.

One file, two readings

What the prompter writes is a flat log of what happened and when. What an editor wants is coloured, grouped and opinionated. Those are the same file, read twice.

Three columns, no colours, no grouping, no opinion about which take was any good. Everything in the strip above was worked out from those rows.

Structure comes from matching arguments

Two tokens that share an argument bracket a span. Neither has a handler, neither does anything on the glass beyond rendering as a chip, and both land in the log — which is all a span needs.

<|Marker::in: quick-hits|>  Three things happened this week. …
<|Marker::out: quick-hits|> And that's the lot.

This is a convention rather than a feature. Nothing enforces it, nothing validates it, and an unrecognised token logs exactly like a recognised one, so you can invent whatever vocabulary your edit needs and it will survive the trip intact.

Retakes sort themselves out

You fluff a line, press ← to get back to the top of the section, and go again. The tokens in that section cross the eyeline a second time and log a second time, further down the take.

The rough cut falls out of that: keep the last span for each name, ripple out everything red, and a nine minute take becomes an assembly without anyone scrubbing for the moment the presenter swore.

What derives from what

Two tokens sharing an argument

A span. The first is its in point, the second its out.

That argument appearing more than once

You went back and did it again. Every pair but the last is a take you rejected.

A pause carrying a duration

A gap of known length — an interstitial, a clip, a sting to drop in.

A token with no partner

A moment rather than a range. A sting, a note to yourself, a punch-in reference.

A timed pause is the useful one for interstitials: the token carries its own length, so the hole it leaves has both ends. An indefinite hold has no length in the file — its end is wherever the next cue lands, which is close enough for a rough cut and exact enough to find.

Handing it to an editor that reads

The cue log opens by itself when a take ends, and copies to the clipboard as CSV. It is small, plain text, and explains its own clock in the first row — which makes it a good thing to hand to something that can act on it.

Why the file stays stupid

It would be easy to have the prompter decide which take was good and write that into the export. It would also be wrong occasionally, and a wrong judgement baked into a file is much harder to notice than one made at the point of reading it.

So the export records only what it can be certain of: a thing happened, this is its name, this is the frame it happened on. Interpretation is cheap and can be redone as many times as you like. A timecode that is quietly four seconds out cannot be recovered from at all — which is why the first row of every export names the clock the take ran on.