What the App Fills In Before You Type

A digital take record is not typed from scratch. SlateX can prefill or derive take number, shot number, reel and clip identifiers, the software sound-roll number, and some timecode and camera values carried through particular creation paths. Prefill depends on the entry path: if the manual new-take form receives no timecode from upstream, its in-point field stays blank; recording and quick-capture paths pass in a current reading.

Prefill answers “what goes in first,” not “has this value been verified on set?”

Take and shot numbers come from the existing structure

A new take number is one more than the larger of the highest surviving number under the current shot and the highest number that shot has ever used. It is not based on the current record count, so deleting a middle or highest-numbered take does not free that number. The script supervisor can edit the field; a larger valid positive number means the next take continues above it, but entering a smaller number does not make the next take go back below the highest number already used. A deleted number does not come back into circulation; Why the Next Take Does Not Fill a Deleted Number covers that boundary in detail.

Shot numbers are also generated from the active naming mode. The current modes belong to two families: one continues with alphabetic suffixes after the scene number, while the other uses a scene number with a hyphenated numeric suffix. This is a naming rule, not a judgment about what the next setup should be called. Shot management remains the place where a shot name can be reviewed or changed.

Generated numbering should not be read as a guarantee that the resulting identity is correct. Scene, shot, and take identities still need to be checked against the script and the day’s record, especially after deletions, renaming, or different record-creation paths.

Reel, clip, and sound-roll numbers have fixed display formats

The new-take form’s camera draft starts with camera letter A, reel number 1, clip number 1, and sound-roll number 1. The interface can therefore show values such as A001, C001, and S001: reel is shown as the camera letter plus a three-digit reel number, clip is shown as three digits, and the sound-roll number carries an S in front. These are identifiers built from the camera letter and numbers; they do not prove that the physical camera card, editing media, or sound report uses the same identifier.

Keep software numbering separate from reported names. The camera-card label is a separate field from the displayed reel. The bottom-bar increment/decrement controls change only the sound-roll number, not the sound-roll name reported by the sound department. CSV likewise has separate Reel and Camera Card columns, and separate Sound Roll and Sound Roll Reported columns. A displayed number must not be treated as proof of an external report value. For why a reel name carries a camera-letter prefix, see Where Reel Names Like A001 Come From—and Why the Prefix Follows the Camera.

Clip preview and actual number issuance are different

Each camera’s saved definition holds the next reel and clip identity to use. When recording starts, the app uses that value for the camera if a definition is available and advances the next one; saving the new-take form does the same when it finds the matching camera definition. After clip 999, the next identity moves to the next reel and clip 001, rather than silently reusing 001 on the same reel.

The number shown in the form is a draft preview. If a camera definition is available, the form initially shows that definition’s next clip number. If it is initialized from the previous take instead, the draft may display the previous clip number plus one. At save time, a matching definition supplies the actual reel and clip; only when no matching definition is found does the save path fall back to the draft numbers. It is therefore inaccurate to say that saving the new-take form never advances the clip identity, or to treat the form preview as the final media identifier.

The initial in-point value depends on the entry path

When the new-take form is opened manually without an upstream timecode, the in-point stays blank. The app explicitly avoids filling the field from the device clock or fabricating a complete-looking timecode with frame position 00.

The recording path captures a reading at the moment recording starts. The quick-capture path captures readings at start and stop, then passes them into the new-take form. A reading may come from a recent Bluetooth device packet or from software projecting forward from the most recent reading, and a source marker is shown with the reading. Without a usable baseline, the display may still be a placeholder rather than a valid timecode.

Do not describe every entry path as “automatically filling the device’s current hour, minute, second, and frame 00,” and do not infer the source just because the field contains characters. This section concerns the take’s in-point; the camera-level sound start timecode, Sound TC, is a separate field that starts blank and is carried or entered through its own camera field.

The out point is the reading on screen at the moment you stop

The out point comes from the reading displayed at the moment you call stop. It is what that stop action captured, not a separate confirmation that the media’s actual out point has been verified; compare it with your own record and media before relying on it as a boundary.

Camera letters and inherited parameters depend on the action

The camera-letter alphabet is A through Z. An add-camera action chooses the first currently unused letter; if all letters are occupied, that action refuses to add another camera rather than falling back to A.

“Add camera” does not mean one universal parameter-copy operation:

Adding a project-level camera definition assigns an unused camera letter, starts reel and clip numbers at 001, and carries over the previous camera’s sound-roll number (or starts at 1 if there is no previous camera). It does not copy the previous camera’s lens, aperture, ISO, frame rate, or other technical settings as facts about the new physical camera.

Adding a camera in the new-take form copies reel, clip, frame rate, shutter, white balance, sound-roll number, sound-roll name, and sound start timecode from the last camera in that form. Camera-card name and timecode mode are not in that button action’s copy list; neither are lens, aperture, ISO, focus distance, composition fields, or VFX flags.

Adding a camera to an existing take carries over reel, clip, frame rate, shutter, white balance, sound-roll number, sound-roll name, and sound start timecode. It still does not copy every field from the previous camera.

A different case is opening the new-take form and prepopulating the cameras already in the draft. If project-level camera definitions are available, those definition rows supply values, with current shot presets able to override frame rate, shutter, white balance, or LUT; composition fields and focus distance are cleared. If the form instead initializes from the previous take, a same-shot continuation keeps focus distance, while a new shot clears it; lens and aperture are retained in both branches. This initialization logic is not the same operation as clicking “Add camera.”

With multiple cameras, per-camera records are not shot-level fields

A multi-camera take stores a separate camera setting for each camera. Each camera’s own frame rate, shutter, white balance, sound roll, and sound start timecode travel with that camera’s record rather than being merged into one value shared by the whole take.

The current behavior therefore does not support the claim that “the last camera processed overwrites the shot-level four parameters during take creation.” A value shown at shot level and a value saved or delivered for an individual camera need to be checked separately. A field that was not copied by one add-camera action should not be assumed to have been inherited merely because a preset exists elsewhere.

Shooting-day assignment comes from the record relationship, not today’s calendar date

Saving a new take links it to the shooting day resolved for that scene; the recording path attaches the day the same way rather than simply writing the device calendar’s “today.” Export can run for a single shooting day or for the whole project: the day scope only takes takes attached to that day, while the project scope takes the project.

So, prefilled take, reel, or camera values do not by themselves prove that the shooting-day link exists. Before a day-specific handoff, verify that the take is actually attached to the intended shooting day; a take without that link will not appear in that day’s export.

FAQ

Does deleting a take make its number available again?

No. The next number is one more than the larger of the highest surviving take number and the highest number that shot has already used. Deleting a take does not lower that highest number.

If a new take already shows an in-point, did it come from the on-set timecode source?

Not necessarily. A manually opened form with no upstream timecode leaves the in-point blank. Recording or quick-capture paths pass in a current reading, whose source may be a device packet or a reading estimated by the software. Check the source marker and the on-set record rather than relying on the presence of text.

Does adding a camera copy every parameter from the previous camera?

No, and the answer depends on the entry point. Adding a project-level camera definition sets its identity, reel/clip starting values, and sound-roll number; the add-camera buttons inside a new-take form or an existing take carry over a limited set of fields rather than copying the whole camera record.

Does the clip number advance every time a take is created?

When a matching camera definition exists, both recording start and new-take save take the next reel/clip value and advance it. If no definition matches, the new-take save falls back to the draft reel/clip values. The draft preview is not always the final issued value.

Can records be exported for a single shooting day?

A day-scope export is available, and it requires the take to be attached to the intended day. Prefilled identifiers do not prove that the link exists.

Axiom One LLC — SlateX