Which Multicamera Take Identifiers Are Shared and Which Stay Separate
One take can contain several camera records, but belonging to the same take does not mean every camera field should be merged. Scene, shot, and take identify the shared take context, while values such as reel, clip identifier, and sound roll belong to the individual camera records.
Multicamera records share the identity framework of one take, while each camera’s reel, clip identifier, and sound roll still need to be verified separately.
How camera letters are assigned
When a camera is added, its camera identifier is chosen from the available letters in order. The system takes the earliest currently unused letter, and once the whole letter set is occupied no new letter is assigned: the add action is refused with a short message rather than falling back to a default camera identifier. This rule assigns camera identity; it does not merge media fields from different cameras.
Several cameras inside one take can therefore share the scene, shot, and take context while retaining separate camera identifiers. Scene, Shot, and Take Numbers Explained covers those record layers; the boundary here is to keep them distinct from camera-level fields. During receiving, the take’s identity and the camera’s identity should be read together.
Which values carry forward when a camera is added
When the add-camera control in the take create and edit forms is used, the new camera carries forward reel number, clip identifier, frame rate, shutter, white balance, and sound-roll number from the previous camera. Lens, aperture, ISO, focus distance, composition fields, and VFX do not carry forward, while camera model, resolution, aspect ratio, and LUT start from empty defaults. The new-camera button in the script page’s bottom toolbar follows a different rule: reel and clip return to their starting values, while ISO, camera model and LUT carry forward. Carry-forward behavior supplies initial values for the new camera form; it does not turn two camera records into one.
Which Camera Parameters Carry Forward When You Add a Camera gives the fuller field-by-field treatment of that behavior. The identity boundary to keep here is that a value remains a field of the new camera after it is saved even if its initial value came from another camera. The receiver should not merge two cameras’ reels or clip identifiers merely because their starting values happened to match.
“Carried forward as an initial value” and “shared as one field in delivery” are different statements; multicamera handoffs still expose these values by camera record.
Why composition fields do not follow one universal carry-forward rule
Whether composition fields carry forward depends on where you add the camera: adding from the take form clears shot size, camera angle, movement and focus distance; adding from the script page’s bottom toolbar carries focus distance only when the shot is unchanged, and clears it when the shot changes. The accurate external boundary is that composition carry-forward depends on where you add the camera.
It would therefore be incorrect to state a single rule saying that a new camera always keeps the previous composition or always clears it. The user should inspect the current fields after adding the camera and confirm them against the actual setup. This difference does not change the fact that reel, clip identifier, and sound roll remain camera-level values belonging to each camera.
Why the three handoff views expand multicamera records differently
ALE, CSV and PDF all emit rows per camera, so one multicamera take appears as separate camera rows in those files, and a take with no camera still holds one row. These expansion differences are exactly what the article Why the Same Takes Do Not Line Up Row-for-Row Across Handoff Files is about.
There is another receiving boundary: a camera that was turned off on set never reaches the handoff at all — ALE, CSV and PDF all draw on the cameras that actually took part in the take. The PDF body prints one row per participating camera but has no camera-number column, so camera identity there can only be read from the leading letter of the camera roll value; ALE and CSV have their own camera column. The receiver should still check that identity against the on-set record.
Why deleting a camera should be kept separate from take identity
The delete-camera entry point is offered only when a take contains more than one camera, so that entry point cannot be used to reduce the take to zero cameras. That is the confirmed boundary of the control and should not be expanded into a claim that deleting one camera deletes the take record itself. A take record and a camera record remain separate layers and should be treated that way during receiving.
For final verification, first use scene, shot, and take to identify the take, then use the camera identifier to identify the camera, and then verify reel, clip identifier, and sound roll separately. Values that originated through carry-forward should not be merged merely because the cameras belong to the same take. Multicamera identity means a shared take context with preserved camera-level field boundaries.
FAQ
Should reel values from several cameras in the same take be merged?
No. Reel, clip identifier, and sound roll belong to each camera record and should be verified together with each camera identifier.
Which fields carry forward when another camera is added?
When the add-camera control in the take form is used, reel number, clip identifier, frame rate, shutter, white balance, and sound-roll number carry forward; lens, aperture, ISO, focus distance, composition fields, and VFX do not under this rule. Camera model, resolution, aspect ratio, and LUT begin from empty defaults.
Does PDF expand every camera in the same take?
It does. PDF prints one row per camera that took part in the take, and ALE and CSV emit rows per camera as well.
Is a camera that was turned off automatically excluded from the handoff selection?
It is. A camera that was turned off and did not take part in the take never reaches the handoff, so every camera that appears there was participating. The receiver should still check that row’s camera identity against the on-set record.
Axiom One LLC — SlateX