Scene, Shot, and Take Numbers Explained

Scene, shot, and take numbers identify three different layers. A scene number points the record back to a scene in the script. A shot number distinguishes a camera setup within that scene. A take number distinguishes repeated attempts under the same shot. SlateX follows the same hierarchy: scenes contain shots, and shots contain takes. These numbers should not be treated as one continuous counter because they answer different identity questions.

Scene asks “which scripted scene,” shot asks “which setup,” and take asks “which attempt under that setup.”

Scene number is script identity, but renaming it does not rewrite old shot numbers

The scene number belongs to the scene record and can be changed in scene management. One boundary matters immediately: changing the scene number does not automatically rename shot numbers that were already created.

If a scene was numbered 5 and existing shots were named in forms such as 5A or 5-1, changing the scene to another number leaves those existing shot strings intact. Later output that combines the new scene number with an old-prefixed shot can therefore expose the mismatch.

A scene-number change is not merely a cosmetic edit. After renaming a scene, review the shots already under it and decide whether their names still follow the intended convention.

Shot number identifies the setup and follows one of two built-in naming families

SlateX generates shot numbers from the current naming mode. The present modes belong to two families: a scene number followed by alphabetic suffixes, or a scene number followed by a hyphenated numeric suffix.

That naming preference is device-level state. It does not travel as project data with an account, so another device should not be assumed to have the same convention selected.

A shot number can be changed in shot management, but the take-record screen is not a direct shot-number entry field. The two available generation families should also not be described as an arbitrary custom naming system; they are the built-in modes currently provided.

Take number identifies repeated attempts and has no manual edit field

Take numbers are generated from the highest take number already present under the current shot, plus one. The UI does not provide a field for typing or editing a take number directly.

One consequence is that deleting a take in the middle does not cause a later take to fill the missing number. The next number is not based on how many take records remain; it is based on the highest surviving number.

A take sequence therefore should not be promised to remain gap-free. The number is an identity within the shot, not a formatting exercise designed to keep every integer present.

A gap can remain. Preserving record identity matters more than making the numbers look continuous.

In multicamera records, take identity can match while camera identity stays separate

One take can contain several camera records. They can share the same scene, shot, and take identity because they belong to the same recorded attempt, while reel, clip, and camera identifiers remain separate for each camera.

During receiving, identical take numbers should not cause multiple camera rows to be collapsed into one media identity. Scene, shot, and take establish the record hierarchy; camera, reel, and clip continue the identification within that take.

Master and Coverage are derived from the shot-number shape

The current UI derives Master versus Coverage from whether the shot number contains a letter. A shot number with no letter follows one display path; a number containing a letter follows the other. There is not a separate user-editable Master/Coverage type being stored for this behavior.

Renaming a shot can therefore change the derived classification. Turning a non-letter form into a form that contains a letter can move it to the other grouping in the interface. It would be inaccurate to describe this as the user manually tagging a shot as Coverage.

There is one more boundary around identity: these numbering invariants live in application logic, and the data model carries no uniqueness constraint. Manually adding a scene or an episode does not run a duplicate check either. Receiving and cleanup should still check for duplicates and for historical shot names that no longer match a renamed scene.

FAQ

What do scene, shot, and take numbers each identify?

Scene identifies the scripted scene, shot identifies a setup within that scene, and take identifies a repeated attempt under the same shot. Together they form the record hierarchy.

Can a take number be edited manually?

The current UI has no manual take-number field. A new take uses the highest existing take number under the shot plus one, so deleting a take in the middle does not cause that gap to be reused.

Does the shot-naming mode travel to another device with the account?

Do not assume that. The current shot-naming preference is device-level state rather than project entity data, so another device should verify its own setting.

Is Master or Coverage a type the user marks manually?

Not in the current model. The UI derives that distinction from whether the shot number contains a letter, so changing the shot number itself can change the classification.

Axiom One LLC — SlateX. Figures current as of 24 September 2026.