What a Take Record Needs for Handoff

Q: Does one shot always keep only one Circle?

Setting a take to Circle demotes the previous Circle in that shot to Keep. The take list, the new-take form and the edit sheet save through one write path, so the entry point does not change the result; the demotion moves the rating level with the status and never crosses shots. Which take the crew circled is still confirmed in the Daily Log.

A take record is useful for handoff when the next person can answer a short set of practical questions: which shot and take is this, what did each camera record, what status was assigned on set, where does the take begin in time, what exception needs a note, and where are the related continuity assets. In SlateX, the current record path covers the take number, camera collection, status, in-point and out-point timecode, the two duration fields the screen shows — “Scene duration”, typed in by the supervisor, and the read-only “TC duration” that subtracts those two readings — take notes, and continuity-asset binding. With multiple cameras, each camera keeps its own parameter set.

A handoff-ready take record is not a pile of fields; it is a traceable path from “which take” to “which camera, what status, what time, and what evidence.”

Start by making the take identifiable

Identity comes first. A take number needs the shot it belongs to, otherwise “take three” has no stable context once the record leaves the person who created it. SlateX associates the take with its shot and carries the take number through the record flow. When reading a take record, treat shot context and take number as one identity pair rather than reading the take number in isolation.

The record also needs camera-specific information that can distinguish the media captured for that take. With multiple cameras, SlateX does not reduce them to one shared camera description. Each camera has its own parameter group. For handoff, camera ID, reel, clip number, and frame rate are the first identity cues a receiver can check; the on-set record can also carry lens, aperture, focus distance, color temperature, sound roll, and camera notes. The point is not to advertise a field count. The point is to keep each camera’s identity separate.

Reel and clip information should stay attached to the camera

When one take has several cameras, reel and clip information should be checked per camera. SlateX carries the current camera collection into a new take, and a newly added camera starts from inherited camera parameters that can then be changed on set. That only describes how parameters carry over; no time-saving, error-reduction or context-loss effect has been measured here. A receiver should still read each camera’s reel, clip number, and other parameters as its own record. For which identifiers a multicamera take shares and which stay separate, see “Which Multicamera Take Identifiers Are Shared and Which Stay Separate”.

Those camera-level values also feed later camera-specific handoff output, which is another reason to keep them distinct at the take-record stage. Reel and clip text can vary with on-set habit, so this article treats those fields only as “what is currently recorded for this camera.” It does not present a naming pattern as something already accepted by a downstream receiving workflow.

Record the on-set status; Circle is exclusive within a shot, not across shots

SlateX uses the on-set status labels Circle, Keep, Hold, and N/G. Their handoff job is straightforward: the next person can see how the take was judged on set without having to infer that judgment from a free-text note. Status belongs in the take record, and one shared write path maintains the same rule wherever you save it.

Setting a take to Circle demotes the previous Circle in that same shot to Keep. The take list, the new-take form and the edit sheet save status through one write path, so where you save does not change the result; the demotion writes status and rating level in the same pass (Circle stepping down to Keep moves the rating with it), touches no other fields and never crosses shots. Read the mark from the cell each record carries, and still say in the Daily Log which take the crew circled — that judgment belongs to the workflow, not to the software picking a take.

One more boundary belongs in the handoff: the mark is visible differently in each delivered file, so neither “it always travels” nor “it never travels” is correct. The ALE now carries Rating and Circled take, which say what the mark on that take was; but it is a matching document, not the channel that tells an editor which take to love — circled takes still get written into the Daily Log and said out loud. CSV has English rating text (Circle / Keep / Hold / N/G, not localized), plus a Circle column that writes only TRUE or FALSE and writes TRUE only for Circle — so a take marked Keep reads back as FALSE there. PDF has a rating column in its header, drawn as a colored dot plus English text. A receiver should therefore read the mark per file and per column, and not infer from “what was marked in the app” that “the same mark must appear in the exchange file”.

Status records an on-set judgment; one shared write path keeps a single Circle per shot, while which take was circled still has to be said in the Daily Log.

Timing should locate the take, not just produce a precise-looking string

A handoff-ready take needs a time position. The current interface can record an in-point timecode, an out-point timecode and “Scene duration”: the in-point can be populated from the running timecode when the take is created, the out-point is the reading on the screen at the moment of stop, captured by the recording chain or copied off the camera by hand, and “Scene duration” is what the supervisor types off their own stopwatch — that field arrives empty and is never prefilled. Together they answer “where does this take sit on the media?” and “how long did the action actually run?” The screen also shows a read-only “TC duration”, the two readings subtracted with the tail frame excluded, and that same span goes into the machine-readable files. A span and a typed stopwatch disagreeing is a set norm rather than a mistake, since preroll, the slate and a director who rolls early all sit inside the stopwatch. Read these values with the shot, take number and camera context rather than as an isolated, precise-looking string.

The boundary matters here: a take-record checklist should only include time fields that the interface can actually capture. A column appearing in an export is not enough. If there is no on-set input path for it, it should not be promoted into the handoff list. That keeps the article aligned with what a person can really record rather than what an export happens to contain.

Use notes for exceptions and continuity assets for evidence

Structured fields can identify the take, camera, status, and timing, but on-set exceptions do not always fit a fixed list or a number. The take note is the place for specific context that the structured fields do not express. A useful note should add the missing fact, not repeat the take number or reel that is already stored elsewhere.

Continuity assets serve a different role. It is evidence rather than prose. SlateX can bind continuity assets to the take, allowing the next person to return from the record to the relevant photo or video instead of searching an unstructured album without take context. The image does not decide which continuity state is correct; the take record’s job is to keep the evidence attached to the production event it came from.

A practical order for checking a take record

Start with shot and take identity. Then inspect each camera separately for camera ID, reel, clip number, and the camera information needed for the handoff. Next read the Circle, Keep, Hold, or N/G status. After that, verify the in-point and out-point timecode, “Scene duration”, and the read-only “TC duration”. Finish with the take note and continuity-asset binding to make sure exceptions and evidence remain attached to the take.

What we cannot do today is treat every column that appears in an export as an on-set input field. This checklist includes only information that the current interface can capture or that the current record flow supplies. Columns with no input path stay outside it. This is also not a universal industry take-record template; it is a narrow description of what the current SlateX take record can hand to the next person.

FAQ

What should be checked first when handing off a take record?

Start with the shot and take number, then inspect each camera’s camera ID, reel, and clip number, followed by the Circle, Keep, Hold, or N/G status, in-point and out-point timecode, “Scene duration”, take note, and continuity-asset binding.

Should several cameras in one take share one reel and clip value?

Each camera has its own parameter group; when one take contains several cameras, check reel, clip number, and other camera information separately for each camera instead of collapsing them into one shared value.

Does one shot always keep only one Circle?

Setting a take to Circle demotes the previous Circle in that shot to Keep. The take list, the new-take form and the edit sheet save through one write path, so the entry point does not change the result; the demotion moves the rating level with the status and never crosses shots. Which take the crew circled is still confirmed in the Daily Log.

What jobs do timecode and notes perform in a take record?

The in-point and out-point timecode locate the take in time and “Scene duration” says how long the action ran, while the take note carries an on-set exception that structured fields do not express; both should be read with the shot, take number, and camera context.

Axiom One LLC — SlateX