It is obvious just from looking at them that racks with adjustable tube angles must not be configured with their tubes angling at each other.   Since the addressing operation in Finale 3D assigns effects to rack tubes, it is the addressing operation itself that ultimately determines the angles of the tubes of adjustable angle racks, by virtue of the effect angles assigned to them.  Thus, if you are using adjustable tube angle racks you must take care in the addressing operation to ensure the angles will not collide. Figure 1 – Before and after rearrangement.  The right image has no collisions (and a nice pin order).   If you check the "Rearrange effects in adjustable angle racks to avoid collisions" checkbox on the addressing dialog shown in Figure 2, then after the tubes are assigned in the original phase of the addressing operation, a second phase will rearrange the effects within each adjustable angle rack to avoid collisions.   Since the rearrangements only occur within the confines of the racks, they will not violate any of the addressing constraints in the addressing dialog.  For example, if you restrict racks to a single module, the rearrangements within any rack wouldn't have any effect on that.  The rearrangement will take into consideration any tube angles or tube angle ranges that are set in the definition of the rack.  For example, if you've defined a rack to have the rack structure "Single-shot rack, adjustable fan angles of tubes within each row", and if you've specified some of the tube angles or tube angle ranges in the rows (see Tube angle range constraints), then the rearrangement will only move effects to tubes permitting the angles of the effects.   Figure 2 – The "Rearrange effects" checkbox is the easiest way to avoid collisions.  Just check the box, that's all you need to do.   Optimizations In addition to eliminating tube collisions, which is a guarantee, the "Rearrange effects" function renumbers the pins and optimizes the rearrangement for symmetry, balance, aesthetics, and ease of loading.  These secondary optimizations are not guarantees but they are a nice fringe benefit of the function.  The optimizations in order of priority are, No angle collisions or angle range violations No pin sequence gaps No shooting over empty holders Symmetry of angles and pins Balance Referring back to Figure 1, the renumbered pin sequences work from the outside toward the center if the rack uses multiple modules.   Limitations The "Rearrange effects" option only works on non-cake racks of these three rack structures: Fully adjustable tube angles Tiltable row angles Fannable tube angles in each row Additional limitations apply if the rack shares pins or modules with other racks, or if the rack contains locked addresses, or if the rack has a usable length limit on the rows, or rows with different numbers of tubes, or multiple tube sizes.   The full list of limitations is in Table 1. Please ensure that your racks are oriented in the layout in such a way that their tubes can be angled in the directions of the effects.  Tiltable row racks need to be oriented with their rows vertical in the layout if the effect angles are side to side so the fans are perpendicular to the rows, to enable the rows to tilt for the fan angles.  Fannable tube angle racks need to be oriented with their rows horizontal in the layout if the effects are side to side so the rows are parallel to the fans.  Fully adjustable tube angle racks could be oriented with their rows vertical or horizontal for side to side effect angles, but if they have a usable length limit then they must be oriented with their rows horizontal because the usable length limit restricts the rearrangement to apply within each row instead of globally.   Table 1 – Limitations of rearrangement for racks based on their rack structure Rack structure Locked effects or non-existent addresses Shared pins w/ other cake racks Usable length limit; multiple row sizes; or multiple tube sizes Shared pins w/ other pre-wired pin racks or non-cake racks Shared rails w/ other non-cake racks Single-shot rack, fully adjustable tube angles EXCEPTIONS: locked effects neither moved nor renumbered OK REDUCED FUNCTIONALITY: rearranges within each row instead of globally; DISABLED if rows not parallel to fans EXCEPTIONS: these effects can be moved  but cannot be renumbered EXCEPTIONS: avoids renumbering effects to pin numbers that are used in other non-cake racks Single-shot rack, fannable tube angles in each row EXCEPTIONS: locked effects neither moved nor renumbered OK REDUCED FUNCTIONALITY: rearranges within each row instead of globally; DISABLED if rows not parallel to fans EXCEPTIONS: these effects can be moved  but cannot be renumbered EXCEPTIONS: avoids renumbering effects to pin numbers that are used in other non-cake racks Single-shot rack, tiltable rows DISABLED if any locked effects OK OK EXCEPTIONS: these effects can be moved  but cannot be renumbered EXCEPTIONS: avoids renumbering effects to pin numbers that are used in other non-cake racks Candle rack, fully adjustable tube angles EXCEPTIONS: locked effects neither moved nor renumbered OK REDUCED FUNCTIONALITY: rearranges within each row instead of globally; DISABLED if rows not parallel to fans EXCEPTIONS: these effects can be moved  but cannot be renumbered EXCEPTIONS: avoids renumbering effects to pin numbers that are used in other non-cake racks Pre-wired single-shot rack, tiltable rows DISABLED if any locked effects or any holders pre-wired to non-existent addresses, e.g.,  a 35 holder rack with a 32 pin module OK OK DISABLED if any DISABLED if any row contains empty holders pre-wired to pins that are used in other non-cake racks Pre-wired single-shot rack, fannable tube angles in each row DISABLED if any locked effects DISABLED if any REDUCED FUNCTIONALITY: rearranges within each row instead of globally; DISABLED if rows not parallel to fans DISABLED if any EXCEPTIONS: cannot move effects into empty holders pre-wired to pins that are used in other non-cake racks Pre-wired single-shot rack, fully adjustable tube angles DISABLED if any locked effects DISABLED if any REDUCED FUNCTIONALITY: rearranges within each row instead of globally; DISABLED if rows not parallel to fans DISABLED if any EXCEPTIONS: cannot move effects into empty holders pre-wired to pins that are used in other non-cake racks Pre-wired candle rack, fully adjustable tube angles DISABLED if any locked effects DISABLED if any REDUCED FUNCTIONALITY: rearranges within each row instead of globally; DISABLED if rows not parallel to fans DISABLED if any EXCEPTIONS: cannot move effects into empty holders pre-wired to pins that are used in other non-cake racks Single-shot rack, fixed tube angles (pre-wired or not) DISABLED DISABLED DISABLED DISABLED DISABLED Single-shot rack, fully adjustable posts (all kinds, pre-wired or not) DISABLED DISABLED DISABLED DISABLED DISABLED Mortar rack (pre-wired or not) DISABLED DISABLED DISABLED DISABLED DISABLED Cake rack (all kinds, pre-wired or not) DISABLED DISABLED DISABLED DISABLED DISABLED   Loading order Rearrangement obviously depends on what effects are in the rack, but it does not depend on their initial arrangement. The rack's loading order determines which corner the pin number sequence starts with.  If the rack uses multiple modules, the list is shown in the order the modules are encountered when traversing the tubes in the loading order.   Figure 3 – The two modules A0 and A1 used in this rack are listed with A0 first since it is the first to occur in the loading order.   The 30 tube rack in Figure 3 uses the first 15 pins of two modules.  You can tell from the colors of the numbers that the pins in the upper left 0, 1, 2, ... are associated with module A0, but if the colors are too close to tell apart you rely on the logic that the first module in the list (A0 in this case) is the first module encountered in the loading order.  

To create and export a script for the Mongoose firing system, please follow these three steps: Design the show. Address the show ("Addressing > Address show"). Export the script ("File > Export > Export firing scripts"). Step 3 creates the script file, which is a CSV file that you can import into your firing system.   Figure 1 – The Mongoose firing system   The CSV is a human-readable text file that contains the essential information for a firing system controller to fire the show, in addition to some meta-information ("Event ID" and "Group ID") that may facilitate optimization on the controller.  The CSV is comma delimited, using standard Excel-style double quote field wrapping as necessary, e.g., a field containing the caliber 3" is represented as "3""" .   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text MIF UTF-8, no BOM Comma CRLF  The first row in the CSV file is the header row, indicating the names of the delimited fields.  The data rows follow. The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Sort order of rows Loosely speaking, rows are sorted chronologically, but the sort order is affected by Track values if present.  More precisely, rows are grouped by their Track values if they have Track values or by common event time (ignition time) if they do not have Track values.   The resulting groups are sorted relative to each other by their earliest row effect time (effect time, not event time), and the rows within the groups are sorted by their event times.  Thus if there are no Track values, the rows are simply sorted by their event times. What rows represent Each row identifies a unique firing pin ignition (i.e., unique module number, pin address, ignition time), or a DMX command.  If the "DMX Control" field is blank, the row is a firing pin ignition; otherwise the row is a DMX Command and the DMX Control field is an integer identifying what kind of command. Module types Finale 3D supports both 48 and 24 pin module types, with DMX and non-DMX options.  The 48 pin module type also has a variation that splits the contiguous 48 pins into two slats of 24 pins, A and B.  For this option, the Rail Address in Finale 3D includes both a module number and a slat letter (A or B), with pin numbers relative to the slat.  In the exported script, however, the slat-relative pins (1-24) are converted back to module-relative pins (1-48), and only the module number ("Logical ID") is included. mon_48shot - (48 pins) mon_48shot_dmx - (48 pins + DMX) mon_2x24shot - (2 slats of 24 pins) mon_2x24shot_dmx - (2 slats of 24 pins + DMX) mon_8x6shot - (8 slats of 6 shots) mon_8x6shot_dmx - (6 shots + DMX) Special characters Fields include any Unicode characters except tab and newline and other control characters.  Excel-style CSV double quoting is used for double quote and comma within field text. Hazard groups The purpose of hazard groups is to enable the user to disable sections of the show in real time based on evolving conditions as the show progresses, such as wind direction or a detonation in a rack.  In Finale 3D, a user can tag events in the script as members of hazard groups.  The tags are represented in the "Effect Lockout" field of the exported script. Tracks Tracks identify a sequence of events that can be triggered in real time by pressing a button on the controller.  A Track value can be any string of characters.  Events that have the same Track value are said to be in the same track.  A show can contain multiple tracks, and can contain gaps between the tracks (i.e., rows without Track values).  A show can begin with a track, or not.  The only restriction with tracks is that they are not interwoven, with events from one track before and after events from another track or gap. Tracks also affect optimizations in DMX scripts by creating boundaries.  DMX scripts are optimized to remove redundant rows that set a channel value that was already set by a previous row, but this optimization only applies within tracks or gaps.  A row that would be redundant on account of a previous row may not be redundant if the previous row is in a different track or gap.  Each track in a script can only rely on its own rows so tracks can be triggered independently. Meta-data for optimization The MIF script format includes "Event ID" and "Group ID" to facilitate optimization.  The Event ID field is a unique integer identifying the script row in Finale 3D that is responsible for the generating the script row in the exported MIF script.  For pyro, each script row in Finale 3D corresponds to a single script row in the MIF script, one to one, so the Event ID is not useful for optimizing pyro.  But for DMX commands, a single script row in Finale 3D can correspond to multiple MIF rows.  The Event ID may make it possible to recognize re-used groups of MIF rows and to encode them as a multi-cue on the Mongoose system for efficiency. The Group ID field is a unique integer identifying a group of effects in Finale 3D (Use "Script > Groups > Combine as group..." or press the G key to create groups).  Like the Event ID field, the Group ID field identifies a group of MIF rows that may be duplicated multiple times in the MIF script, and thus may be a candidate for optimization by representing them as multi-cues.  Each group instance in Finale 3D has its own Group ID.  If a group in Finale 3D is duplicated, the original group and its duplicate will have different Group  IDs.  Thus the optimization requires identifying groups with different Group IDs that have identical rows with respect to the information stored in the multi-cue. Each script row has the fields shown in Table 3.   Table 3 – Specifications of script fields Field name Description Cue The cue count, beginning with one and incrementing at each new ignition time or at each new track group of effects.  The cue count does not increment within a track group of effects even if the effects in the track group have different ignition times. Event Time The exact time of the firing system's "ignition event" (application of a voltage to a pin) that ignites e-matches or triggers a sequencer that ultimately leads to the ignition of effects. Format is HH:MM:SS.DDD. Prefire The delay from the ignition time to the perceived visual effect.  This delay typically includes the lift time (for shells) plus any fuse time between the ignition time and the first launch of the effect.  Format is in seconds with two digits after the decimal point. Effect Time The time of the first visual effect triggered by the firing system's ignition event, which is generally the break time for shells, and just a small delay or no delay after the event time for ground effects. Format is HH:MM:SS.DDD. Duration For pyro, the duration represents the lifetime of the perceived visual effect, which is usually interpreted for shells as the time from break to dissipation of the stars.    For DMX commands, the duration is either blank, indicating the DMX Start Value should be held indefinitely or until interrupted by another DMX command; or the duration is a time duration, indicating the DMX Start Value should be held for that duration and then changed to the DMX End Value at the end of the duration, or ramped linearly over the duration period from the DMX Start Value to the DMX End Value.  The selected behavior is based on the DMX Control field (see below).   The format of this field is seconds with two digits after the decimal point. Device Count The number of devices (shells) represented by the row.  May be more than one in the case of chains or multiple e-matches connected to the same firing system pin.  The device count is zero for DMX commands. Match Count The number of e-matches required for the row.  The match count is zero for DMX commands. Description The name of the effect.  For DMX events, the description also includes the specific DMX parameter name and offset, such as the phrase following the double slash in this description field for the ignition channel of a one second flame effect:  "SVUFLM2P [011/0017] One Sec Flame // Ignition (+0)" Size The device caliber.  Format is either a number followed by double-quote for inches or "mm" for millimeters, or the string "NA" or blank for effects for which the caliber term is not applicable.  The size field is blank for DMX commands. Category The category field of the effect definition in Finale 3D, as defined in the effects window.  Categories can be any text string the user chooses in Finale 3D. Type The type of effect, as defined in the effects window.  The type value can only be one of the pre-defined, enumerated types defined here: Why is ‘Type’ so important? What depends on it?. Position The name of the launch position. Module Type The module type, as described in Table 2. Logical ID The module number.  The Logical ID also represents the DMX universe.  Please see the discussion of module types in Table 2. Pin Number The pin number, starting with 1.  Please see the discussion of module types in Table 2. Angle An ASCII art representation of the angles of the devices on this shot, made with backslash, vertical line, and forward slash characters. Effect Lockout An identifier for disabling sections of the show in real time during performance.  The value of this field is filled from the Hazard field of Finale 3D and can be any text string. Notes Firing notes from the script pertaining to this row. Part Number The part number of the effect. Track A user-defined identifier for a section of the show, taken from the Track field in Finale 3D. Event ID A unique number identifying the row in the Finale 3D script that is responsible for this row in the MIF script.  See discussion in Table 2. Group ID A unique number identifying effects in a group in Finale 3D.  See discussion in Table 2. DMX Control This field applies only to DMX commands, and is blank for pyro ignitions.  For DMX commands, the DMX Control field is a number 1-3 indicating the interpretation of the duration field as follows: 1 - DmxControlSetStartAndHoldForever 2 - DmxControlSetStartAndChangeToEndAfterDuration 3 - DmxControlSetStartAndRampToEndOverDuration (not yet implemented as of Feb 27, 2021) DMX Channel Base For DMX commands, this field holds the DMX Channel Base of the fixture to which the DMX command applies.  This field is blank for pyro. DMX Channel Offset For DMX commands, this field holds the offset from the DMX Channel Base of the DMX command.   The effective DMX Channel of the command is DMX Channel Base + DMX Channel Offset.  This field is blank for pyro. DMX Start Value For DMX commands, this field holds the start value (0-255) for the command, as controlled by the DMX Control field.  This field is blank for pyro. DMX End Value For DMX commands, this field holds the end value (0-255) for the command, as controlled by the DMX Control field.  This field is blank for pyro.   The example script below combines pyro and DMX commands, as you can see on the timeline of Figure 2. Figure 2 – Example show   The yellow bars on the left of the timeline are groups of three flame shots on the Explo X2 Wave Flamer.  The first red bar is a group of 10 pyro effects.   The stack of red bars are a quick sequence of pyro effects.   Cue,Event Time,Prefire,Effect Time,Duration,Device Count,Match Count,Description,Size,Category,Type,Position,Module Type,Logical ID,Pin Number,Angle,Effect Lockout,Notes,Part Number,Track,Event ID,Group ID,DMX Control,DMX Channel Base,DMX Channel Offset,DMX Start Value,DMX End Value 1,00:00:07.252,0.0,00:00:07.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-01,mon_48shot_dmx,1,,|,,,GFX9064,,13774,0,1,10,0,128, 1,00:00:07.252,0.0,00:00:07.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-01,mon_48shot_dmx,1,,|,,,GFX9064,,13774,0,2,10,1,255,0 1,00:00:07.252,0.0,00:00:07.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-01,mon_48shot_dmx,1,,|,,,GFX9064,,13774,0,2,10,4,165,0 2,00:00:07.592,0.0,00:00:07.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-01,mon_48shot_dmx,1,,|,,,GFX9064,,13774,0,2,10,2,255,0 4,00:00:09.252,0.0,00:00:09.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-02,mon_48shot_dmx,1,,|,,,GFX9064,,13775,0,1,20,0,128, 4,00:00:09.252,0.0,00:00:09.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-02,mon_48shot_dmx,1,,|,,,GFX9064,,13775,0,2,20,1,255,0 4,00:00:09.252,0.0,00:00:09.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-02,mon_48shot_dmx,1,,|,,,GFX9064,,13775,0,2,20,4,165,0 5,00:00:09.592,0.0,00:00:09.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-02,mon_48shot_dmx,1,,|,,,GFX9064,,13775,0,2,20,2,255,0 7,00:00:11.252,0.0,00:00:11.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-03,mon_48shot_dmx,1,,|,,,GFX9064,,13776,0,1,30,0,128, 7,00:00:11.252,0.0,00:00:11.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-03,mon_48shot_dmx,1,,|,,,GFX9064,,13776,0,2,30,1,255,0 7,00:00:11.252,0.0,00:00:11.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-03,mon_48shot_dmx,1,,|,,,GFX9064,,13776,0,2,30,4,165,0 8,00:00:11.592,0.0,00:00:11.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-03,mon_48shot_dmx,1,,|,,,GFX9064,,13776,0,2,30,2,255,0 10,00:00:13.252,0.0,00:00:13.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-04,mon_48shot_dmx,1,,|,,,GFX9064,,13777,1,1,40,0,128, 10,00:00:13.252,0.0,00:00:13.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-04,mon_48shot_dmx,1,,|,,,GFX9064,,13777,1,2,40,1,255,0 10,00:00:13.252,0.0,00:00:13.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-04,mon_48shot_dmx,1,,|,,,GFX9064,,13777,1,2,40,4,165,0 11,00:00:13.592,0.0,00:00:13.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-04,mon_48shot_dmx,1,,|,,,GFX9064,,13777,1,2,40,2,255,0 13,00:00:15.252,0.0,00:00:15.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-05,mon_48shot_dmx,1,,|,,,GFX9064,,13778,1,1,50,0,128, 13,00:00:15.252,0.0,00:00:15.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-05,mon_48shot_dmx,1,,|,,,GFX9064,,13778,1,2,50,1,255,0 13,00:00:15.252,0.0,00:00:15.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-05,mon_48shot_dmx,1,,|,,,GFX9064,,13778,1,2,50,4,165,0 14,00:00:15.592,0.0,00:00:15.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-05,mon_48shot_dmx,1,,|,,,GFX9064,,13778,1,2,50,2,255,0 16,00:00:17.252,0.0,00:00:17.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-06,mon_48shot_dmx,1,,|,,,GFX9064,,13779,1,1,60,0,128, 16,00:00:17.252,0.0,00:00:17.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-06,mon_48shot_dmx,1,,|,,,GFX9064,,13779,1,2,60,1,255,0 16,00:00:17.252,0.0,00:00:17.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-06,mon_48shot_dmx,1,,|,,,GFX9064,,13779,1,2,60,4,165,0 17,00:00:17.592,0.0,00:00:17.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-06,mon_48shot_dmx,1,,|,,,GFX9064,,13779,1,2,60,2,255,0 19,00:00:19.252,0.0,00:00:19.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-07,mon_48shot_dmx,1,,|,,,GFX9064,,13780,2,1,70,0,128, 19,00:00:19.252,0.0,00:00:19.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-07,mon_48shot_dmx,1,,|,,,GFX9064,,13780,2,2,70,1,255,0 19,00:00:19.252,0.0,00:00:19.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-07,mon_48shot_dmx,1,,|,,,GFX9064,,13780,2,2,70,4,165,0 20,00:00:19.592,0.0,00:00:19.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-07,mon_48shot_dmx,1,,|,,,GFX9064,,13780,2,2,70,2,255,0 22,00:00:21.252,0.0,00:00:21.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-08,mon_48shot_dmx,1,,|,,,GFX9064,,13781,2,1,80,0,128, 22,00:00:21.252,0.0,00:00:21.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-08,mon_48shot_dmx,1,,|,,,GFX9064,,13781,2,2,80,1,255,0 22,00:00:21.252,0.0,00:00:21.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-08,mon_48shot_dmx,1,,|,,,GFX9064,,13781,2,2,80,4,165,0 23,00:00:21.592,0.0,00:00:21.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-08,mon_48shot_dmx,1,,|,,,GFX9064,,13781,2,2,80,2,255,0 25,00:00:23.252,0.0,00:00:23.252,,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-09,mon_48shot_dmx,1,,|,,,GFX9064,,13782,2,1,90,0,128, 25,00:00:23.252,0.0,00:00:23.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-09,mon_48shot_dmx,1,,|,,,GFX9064,,13782,2,2,90,1,255,0 25,00:00:23.252,0.0,00:00:23.252,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-09,mon_48shot_dmx,1,,|,,,GFX9064,,13782,2,2,90,4,165,0 26,00:00:23.592,0.0,00:00:23.592,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-09,mon_48shot_dmx,1,,|,,,GFX9064,,13782,2,2,90,2,255,0 28,00:00:27.490,0.0,00:00:27.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-01,mon_48shot_dmx,1,,|,,,GFX9064,,13783,3,2,10,1,255,0 28,00:00:27.490,0.0,00:00:27.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-01,mon_48shot_dmx,1,,|,,,GFX9064,,13783,3,2,10,4,165,0 29,00:00:27.830,0.0,00:00:27.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-01,mon_48shot_dmx,1,,|,,,GFX9064,,13783,3,2,10,2,255,0 31,00:00:29.490,0.0,00:00:29.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-02,mon_48shot_dmx,1,,|,,,GFX9064,,13784,3,2,20,1,255,0 31,00:00:29.490,0.0,00:00:29.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-02,mon_48shot_dmx,1,,|,,,GFX9064,,13784,3,2,20,4,165,0 32,00:00:29.830,0.0,00:00:29.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-02,mon_48shot_dmx,1,,|,,,GFX9064,,13784,3,2,20,2,255,0 34,00:00:31.490,0.0,00:00:31.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-03,mon_48shot_dmx,1,,|,,,GFX9064,,13785,3,2,30,1,255,0 34,00:00:31.490,0.0,00:00:31.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-03,mon_48shot_dmx,1,,|,,,GFX9064,,13785,3,2,30,4,165,0 35,00:00:31.830,0.0,00:00:31.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-03,mon_48shot_dmx,1,,|,,,GFX9064,,13785,3,2,30,2,255,0 37,00:00:33.490,0.0,00:00:33.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-04,mon_48shot_dmx,1,,|,,,GFX9064,,13786,4,2,40,1,255,0 37,00:00:33.490,0.0,00:00:33.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-04,mon_48shot_dmx,1,,|,,,GFX9064,,13786,4,2,40,4,165,0 38,00:00:33.830,0.0,00:00:33.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-04,mon_48shot_dmx,1,,|,,,GFX9064,,13786,4,2,40,2,255,0 40,00:00:35.490,0.0,00:00:35.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-05,mon_48shot_dmx,1,,|,,,GFX9064,,13787,4,2,50,1,255,0 40,00:00:35.490,0.0,00:00:35.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-05,mon_48shot_dmx,1,,|,,,GFX9064,,13787,4,2,50,4,165,0 41,00:00:35.830,0.0,00:00:35.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-05,mon_48shot_dmx,1,,|,,,GFX9064,,13787,4,2,50,2,255,0 43,00:00:37.490,0.0,00:00:37.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-06,mon_48shot_dmx,1,,|,,,GFX9064,,13788,4,2,60,1,255,0 43,00:00:37.490,0.0,00:00:37.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-06,mon_48shot_dmx,1,,|,,,GFX9064,,13788,4,2,60,4,165,0 44,00:00:37.830,0.0,00:00:37.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-06,mon_48shot_dmx,1,,|,,,GFX9064,,13788,4,2,60,2,255,0 46,00:00:39.490,0.0,00:00:39.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-07,mon_48shot_dmx,1,,|,,,GFX9064,,13789,5,2,70,1,255,0 46,00:00:39.490,0.0,00:00:39.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-07,mon_48shot_dmx,1,,|,,,GFX9064,,13789,5,2,70,4,165,0 47,00:00:39.830,0.0,00:00:39.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-07,mon_48shot_dmx,1,,|,,,GFX9064,,13789,5,2,70,2,255,0 49,00:00:41.490,0.0,00:00:41.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-08,mon_48shot_dmx,1,,|,,,GFX9064,,13790,5,2,80,1,255,0 49,00:00:41.490,0.0,00:00:41.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-08,mon_48shot_dmx,1,,|,,,GFX9064,,13790,5,2,80,4,165,0 50,00:00:41.830,0.0,00:00:41.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-08,mon_48shot_dmx,1,,|,,,GFX9064,,13790,5,2,80,2,255,0 52,00:00:43.490,0.0,00:00:43.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-09,mon_48shot_dmx,1,,|,,,GFX9064,,13791,5,2,90,1,255,0 52,00:00:43.490,0.0,00:00:43.490,0.82,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-09,mon_48shot_dmx,1,,|,,,GFX9064,,13791,5,2,90,4,165,0 53,00:00:43.830,0.0,00:00:43.830,0.48,0,0,Explo [001] Macro Step RL13 Short,,Explo X2 Wave Flamer,flame,Pos-09,mon_48shot_dmx,1,,|,,,GFX9064,,13791,5,2,90,2,255,0 55,00:00:50.744,0.0,00:00:50.744,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,1,,,,G2XX1000,,13792,6,,,,, 56,00:00:50.844,0.0,00:00:50.844,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,2,,,,G2XX1000,,13793,6,,,,, 57,00:00:50.944,0.0,00:00:50.944,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,3,,,,G2XX1000,,13794,6,,,,, 58,00:00:51.044,0.0,00:00:51.044,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,4,,,,G2XX1000,,13795,6,,,,, 59,00:00:51.144,0.0,00:00:51.144,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,5,,,,G2XX1000,,13796,6,,,,, 60,00:00:51.244,0.0,00:00:51.244,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,6,/,,,G2XX1000,,13797,6,,,,, 61,00:00:51.344,0.0,00:00:51.344,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,7,/,,,G2XX1000,,13798,6,,,,, 62,00:00:51.444,0.0,00:00:51.444,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,8,/,,,G2XX1000,,13799,6,,,,, 63,00:00:51.544,0.0,00:00:51.544,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,9,/,,,G2XX1000,,13800,6,,,,, 64,00:00:51.644,0.0,00:00:51.644,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,10,/,,,G2XX1000,,13801,6,,,,, 65,00:00:57.125,0.0,00:00:57.125,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,11,,,,G2XX1000,,13802,,,,,, 66,00:00:57.225,0.0,00:00:57.225,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,12,,,,G2XX1000,,13803,,,,,, 67,00:00:57.325,0.0,00:00:57.325,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,13,,,,G2XX1000,,13804,,,,,, 68,00:00:57.425,0.0,00:00:57.425,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,14,,,,G2XX1000,,13805,,,,,, 69,00:00:57.525,0.0,00:00:57.525,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,15,,,,G2XX1000,,13806,,,,,, 70,00:00:57.625,0.0,00:00:57.625,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,16,/,,,G2XX1000,,13807,,,,,, 71,00:00:57.725,0.0,00:00:57.725,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,17,/,,,G2XX1000,,13808,,,,,, 72,00:00:57.825,0.0,00:00:57.825,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,18,/,,,G2XX1000,,13809,,,,,, 73,00:00:57.925,0.0,00:00:57.925,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,19,/,,,G2XX1000,,13810,,,,,, 74,00:00:58.025,0.0,00:00:58.025,2.14,1,1,Red Comet,"2""",2 Assorted,comet,Pos-10,mon_48shot_dmx,1,20,/,,,G2XX1000,,13811,,,,,, Figure 3 – Example Mongoose firing system script with subsections and hazard groups.   Table 4 – Example files Download link Explanation test-mongoose-dmx.mif Example exported file  (CSV) test-mongoose-dmx.fin Example show file (FIN)

To create and export a script for the Firelinx firing system, please follow these three steps: Design the show. Address the show ("Addressing > Address show"). Export the script ("File > Export > Export firing scripts"). Step 3 creates the script file, which is a CSV file that you can import into your firing system.   Figure 1 – The Firelinx firing system   The CSV is a human-readable text file that contains the essential information for a firing system controller to fire the show, beginning with a section defining the format version number and defining the list of the user's chosen hazard group names and the bit flags in the script format that correspond to the names, followed by the list of firing rows.  The firing row fields are tab delimited; and therefore Excel-style double quote field wrapping is unnecessary.  A field containing the caliber 3" is just 3", not "3""" .   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text CSV UTF-8, no BOM Tab CRLF  The rows comprising the header section are all preceded with pound sign (#).   The row immediately following the header section lists the column names for the remaining rows, which comprise the firing information. The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Sort order of rows Rows are sorted by ignition time. What rows represent Each row identifies a unique firing pin ignition (i.e., unique rail address, pin address, ignition time). Module types The script implicitly supports both 24 and 64 pin module types, as chosen by the user when addressing the show.  The module type is not explicitly included in the script. Special characters Fields include any Unicode characters except tab and newline and other control characters. Hazard groups The purpose of hazard groups is to enable the user to disable sections of the show in real time based on evolving conditions as the show progresses, such as wind direction or a detonation in a rack.  In Finale 3D, a user can tag events in the script as members of hazard groups by adding one or more user-defined terms (i.e., words) to the Hazard column in the script window.  Each unique term defines a hazard group.  A script event that lists multiple terms in the Hazard field is therefore a member of multiple groups. Tracks The user can divide a script into separately triggered or stepped subsequences by tagging the script rows with the subsequence number in the Track field, beginning with 1.  The user is expected to assign track numbers in increasing order, with no gaps, or optionally not to assign any track numbers for a show that has a single trigger. Header section The header section of the exported script consists of lines beginning with pound sign (#), such as: #firelinxLt #version 1.0 #beginDisableNames #all 1 #wind 2 #endDisableNames The "DisableNames" section maps the hazard group terms to big flags, 1, 2, 4, etc.  The Hazard column of the exported script contains integers summing the bit flags of the groups of which the event is a member. Each script row has the fields shown in Table 3.   Table 3 – Specifications of script fields Field name Description Event Cue The "Event Cue" column contains triggers for subsequences in the show, starting with 1 and counting up based on "track numbers" that the user optionally has assigned in the script. If the show has no track numbers specified and therefore requires only one trigger, the Event Cue is 1 for all rows. Event Time The exact time of the firing system's "ignition event" (application of a voltage to a pin) that ignites e-matches or triggers a sequencer that ultimately leads to the ignition of effects. Format is HH:MM:SS.DDD. Delay The delay from the ignition time to the perceived visual effect.  This delay typically includes the lift time (for shells) plus any fuse time between the ignition time and the first launch of the effect.  Format is in seconds with two digits after the decimal point. Effect Time The time of the first visual effect triggered by the firing system's ignition event, which is generally the break time for shells, and just a small delay or no delay after the event time for ground effects. Format is HH:MM:SS.DDD. Duration The duration represents the lifetime of the perceived visual effect, which is usually interpreted for shells as the time from break to dissipation of the stars. Format is in seconds with two digits after the decimal point. Devices The number of devices (shells) represented by the row.  May be more than one in the case of chains or multiple e-matches connected to the same firing system pin. Description The name of the effect. Size The device caliber.  Format is either a number followed by double-quote for inches or "mm" for millimeters, or the string "NA" or blank for effects for which the caliber term is not applicable. Position The name of the launch position. Module Address The module number in three digits, starting with 001.  Pin Address The pin number, starting with 1. Angle An ASCII art representation of the angles of the devices on this shot, made with backslash, vertical line, and forward slash characters. Hazard The union of the bit flags corresponding to the hazard groups of which this row is a member. Notes Firing notes from the script pertaining to this row. Part Number A user-defined identifier for the effect. The example script below shows an exported script with three subsequences, and thus three Event Cue numbers 1-3 in the first column.  The script contains two hazard groups, "all" and "wind", which are assigned bit flags 1 and 2.  The second row of the script is a member of both groups, so its hazard field contains the number 1 + 2 = 3. #firelinxLt #version 1.0 #beginDisableNames #all 1 #wind 2 #endDisableNames Event Cue Event Time Delay Effect Time Duration Devices Description Size Position Module Address Pin Address Angle Hazard Notes Part Number 1 00:00:00.000 3.02 00:00:03.020 1.53 1 Green Peony 3" Pos-01 001 1 | 1 10008 1 00:00:01.780 2.24 00:00:04.020 1.02 3 (3) Red Chrysanthemum ... 2" Pos-02 002 1 |/ 3 G2SH1000 1 00:00:02.000 3.02 00:00:05.020 1.53 1 Green Peony 3" Pos-03 003 1 | 1 10008 2 00:00:00.000 3.02 00:00:03.020 1.53 1 Green Peony 3" Pos-04 004 1 | 1 10008 2 00:00:01.000 3.02 00:00:04.020 1.53 1 Green Peony 3" Pos-05 005 1 | 1 10008 2 00:00:02.000 3.02 00:00:05.020 1.53 1 Green Peony 3" Pos-06 006 1 | 1 10008 2 00:00:03.000 3.02 00:00:06.020 1.53 1 Green Peony 3" Pos-07 007 1 | 1 10008 3 00:00:00.000 3.02 00:00:03.020 1.53 1 Green Peony 3" Pos-08 008 1 | 1 10008 3 00:00:01.000 3.02 00:00:04.020 1.53 1 Green Peony 3" Pos-09 009 1 | 1 10008 Figure 2 – Example Firelinx firing system script with subsections and hazard groups.   Table 4 – Example files Download link Explanation test_firelinx.csv Example exported file  (CSV) test_firelinx.fin Example show file (FIN)

The "Rack Type" field in the script window allows you to control the matching between racks and effects when you add racks with the "Racks > Add racks for show..." function.  The feature is available in both the Finale 3D Pro and Finale 3D Hobbyist version.  Here's how it works: The add racks dialog gives you a choice of what rack to use for every effect size and Rack Type represented by the effects in the show.  You can give different Rack Types to effects in the script window that you want to handle differently, and then the add racks dialog will enable you to choose what kind of racks to add for the different Rack Types separately.  Here are a few examples, Finale racks. If you have two different kinds of 3” racks for finale chains versus non-finale effects you can set the Rack Type of the finale chains to “finale” (or any other word of your choice).  If you use Easy Racks, that's all there is to it; if you use your own custom racks, then additionally set the Rack Type Default of your custom 3” finale rack to “finale” in the effects window.  Then when you address the show, the finale chains will only go in the “finale” racks. Cakes vs. slices. If your show contains multi-row cakes and also slice-cakes, and if you want to use racks only for the slice-cakes and not for the multi-row cakes, you can set the Rack Type of the slice cakes to "slice" and then ignore the other cakes in the add racks dialog. Fan racks.  If you have a wheel rack that you want to use for a particular fan of shots in the show, you could give the wheel rack the Rack Type Default of “wheel” and also apply the same “wheel” value to the Rack Type of the effect rows in the script that you intend to go into that rack. The Rack Type field works with both Easy Racks and custom racks that you define.  In both cases, the first step for using Rack Type is to unhide the Rack Type column in the script window, as shown in Figure 1.   Figure 1 – Unhide the "Rack Type" field in the script window to edit Rack Type values for the effects in the show.   The script shown in Figure 2 is from the "Cakes vs. Slices" example.  After unhiding the Rack Type column, the user has edited the Rack Type cells of the 10-shot slice cakes by typing the word "slice" into one of the cells and then copy and pasting the word into the other slice effects.   Figure 2 – Edit or copy/paste the Rack Type field to set the Rack Type.  These 10 shot cakes are designated as "slice".   With the Rack Type field differentiating the cake slices from the multi-row cakes, the "Racks > Add racks for show..." function brings up the dialog shown in Figure 3, which includes separate rows for the two kinds of cakes.  If you don't want to allocate racks for the multi-row cakes, you can just check the "ignore" box for that row.   Figure 3 – The add racks dialog includes separate rows for the rack types, enabling you to ignore the non-slice cakes.   If you are using Easy Racks, the "Add racks for show..." function will automatically create an Easy Rack option for every Rack Type in the show.  If the only difference between your finale racks and standard racks in the "Finale racks" example is that the two kinds of racks have different numbers of tubes, then you can use Easy Racks for both kinds of racks, and simply edit the Tubes/rack field of both rows in the dialog to specify the right number of tubes.   Rack Type Default (in the effects window) The effects window has a column called "Rack Type Default."  This field can be used for custom rack definitions.  The "Add racks for show..." dialog only gives you choices that are compatible with each size or Rack Type.  Thus if you set the Rack Type of your cake slice effects to "slice" as in Figure 2 and Figure 3, the dialog will only offer rack choices that have a Rack Type of "slice" as options for you to select in the second cake row in the dialog.  The function automatically constructs an Easy Rack option with the appropriate Rack Type, so you are assured of at least one compatible option, but if you define and use your own custom racks, you need to set their Rack Type Default fields appropriately in the effects window. The Rack Type Default field name includes the word "Default" because it can be used for both racks and effects.  Returning to the "Cakes vs. slices" example, you probably always want your cake slice effects to use slice racks.  You can save yourself some time by setting their Rack Type Default in the effects window.  Then whenever you insert them into the show, the Rack Type Default will be copied to the Rack Type field in the script, and you won't have to manually edit that field in the script.  This technique is useful for effects that always have the same Rack Type.  It wouldn't be useful for effects in the "Fan racks" example, because the effects used in the wheel rack may also be used in other contexts in the show not in a wheel rack, so you'll need to edit the Rack Type field in the script window depending on the context.  

The "Start Module" and "Pre-Assigned Rails" fields of position properties are two ways of specifying the firing system equipment for the position.  For any position, you can use one field or the other, but not both at the same time since they would conflict with each other. Here are two ways to access the properties for positions. To view position properties in a dialog, right click on a position in the design window and select "Edit position properties" To view position properties in a table, go to the Window menu and select "Positions window" The Start Module and Pre-Assigned Rails fields have slightly different purposes. The Start Module field specifies what module number the addressing functions should start counting from when assigning modules to a position.  The module number count beginning with the Start Module continues counting forward in the next position. The Pre-Assigned Rails field is a comma separated list of rail addresses that specify a set of firing system rails that a position can use.  The order of addresses in the list does not matter; they will always be considered in sorted order.  The module number count before the position with Pre-Assigned Rails continues after that position, unaffected by the Pre-Assigned Rails. For firing systems that do NOT have slats, the words "module" and "rail" are synonymous.  For example, the word module means the same thing as rail for Cobra and FireOne.  For firing systems that do have slats, such as fireTEK, the "module" refers to the piece of hardware that has four twelve-pin "slats" connected to it.  For systems like fireTEK that have slats, the "rail address" is the module-and-slat number. Here are a few examples using different firing systems. Cobra To allocate a Cobra 72M to a position, enter four rail (i.e., module) numbers in the Pre-Assigned Rails field, such as 5,6,7,8 FireOne To allocate a single FireOne module to a position, enter the rail (i.e., module) number in the Pre-Assigned Rails field, such as 10 fireTEK To allocate a fireTEK slat to a position, enter the rail-slat numbers in the Pre-Assigned Rails field, such as 11-1, or 11-2, or 11-3, or 11-4 (to identify a specific slat on module 11)   Figure 1 – The Start Module and Pre-Assigned Rails fields are two ways of specifying the firing system equipment for the position.   In the Pro version of Finale 3D, one other difference between Start Module and Pre-Assigned Rails is that Pre-Assigned Rails will show up in the rack layout window for a position even before addresses have been assigned.  Compare the Pre-Assigned Rails field of Figure 1 with the graphical depiction of the slats in the lower left of Figure 2.   There aren't any assigned addresses yet (no pin numbers in the slats), but the slats are still there.  If the position used the Start Module field (specifying 10, say), instead of using the Pre-Assigned Rails field, then there would be no slats drawn in the lower left of Figure 2 until addresses were assigned.  At that point, whatever slats were used by the addresses would show up. It is easy to guess why Start Module doesn't cause modules or slats to appear in the image before addresses are assigned -- the software wouldn't know how many are required!   Figure 2 – The Start Module and Pre-Assigned Rails fields are two ways of specifying the firing system equipment for the position.   Addressing groups The addressing functions divide the full set of positions into separate addressing groups and address the groups one after another.  If positions share modules, the Start Module and Pre-Assigned Rails properties may affect the division of the positions into addressing groups.  The section Addressing groups describes the implications for the sort order of positions, and provides instructions to avoid addressing conflicts that are possible when using Start Module and Pre-Assigned Rails incorrectly.  

Sometimes it is useful to see how many firing system modules and pins you are using while designing the show.  The pin counts, module counts, and pin warning dots options in the Show menu give you a range of choices.  As an example, Figure 1 is a site with four positions.  The option to show unused pins is turned on, as is the option to show pin warning dots. You can see the Left position has 4 remaining unused pins in its last module.  The Center position has 2 remaining unused pins.  Two remaining pins means the last module is "nearly full" (three or fewer pins), so the position also displays an orange "pin warning dot" to let you know you are approaching the end.  The Right position happens to have exactly the right number of effects to fit the module, so it displays a green warning dot, indicating "exact match."  The Back position has one additional effect, spilling over into a new module.  In this example the modules have 18 pins, so that last pin in the Back position consumes the first pin of an 18-pin module, leaving 17 unused and triggering a red warning dot to indicate "just over".   Figure 1 – Real-time "unused" pin counts and warning dots show module utilization as you script.   The Show menu provides options for pin counts, module counts, and pin warning dots.   You can mix and match these features to your liking.  Sometimes people like to see the pin counts while designing.  Other times people like seeing the module counts, or both.  Some people like seeing the total pin counts; other people like seeing the unused pin counts of the last module.  All these options are available in the menu.   Figure 2 – Counts can be based on cues, events, or addresses.   Figure 2 shows the pin warning dots menu options: counts based on 1) cues, or 2) events, or 3) addresses.   Cues are the count of unique event times.  If multiple events are firing at the same time from a position, they count as a single cue.  Events are the count of every row of the script, no matter what the times are.  You might choose to display cue counts or event counts depending on whether you e-match multiple effects at the same time together on the same pin.  Cue counts and event counts are updated in real-time as you design the show. Depending on your addressing constraints, the cue counts and event counts might not match the actual number of pins you use when you address the show, so the third option for the these counts is based on the addresses in the script window.   Addresses are only updated when you address the show, so if you are displaying counts or warning dots based on addresses then it is useful to know the hot keys for re-addressing the show while designing.  The "Addressing > Re-address selected positions" function (hot key = "M") is often used in combination with address-based counts since it offers a convenient way to work on one or more individual positions without affecting the whole show.  The "Addressing > Address show using blueprints assigned to positions" function (hot key = "Control-Shift-P") is an addressing option for the full show that doesn't involve a dialog.

Virtual slats are a technique for dividing the pins of a firing system module into groups (virtual slats) that you can control with addressing constraints.  Virtual slats aren't required for firing systems that have three part addresses (module/slat/pin) but modules with two part addresses (module/pin) can use virtual slats to divide their pins into groups that correspond to physical slats in the real world (see also, Slats, virtual slats, and splitter boxes).   Figure 1 – Without using virtual slats, a 48 pin module allocates pins to both rack groups with pins counting up from 1.   Consider the Mongoose firing system module shown in Figure 1 in the lower left.  In the real world, the module has 48 pins, distributed in two boxes of 24 pins each.  If you were addressing the position shown in Figure 1, you might want to associate one of the 24-pin boxes with the red racks and the other box with the large blue rack, and divide the addresses accordingly with one group of racks consuming pins starting from 1 in the 48-pin module and the other consuming pins starting from 25.  The ideal addressing assignment might look like that shown in Figure 2.   Figure 2 – Two 24-pin virtual slats can represent ideal pin ranges for the red racks and blue racks.   Figure 2 shows the same 48-pin module represented as two 24-pin virtual slats in the lower left.  Although this image doesn't show the wires, you can see by matching the numbers that the right slat addresses the four pins of the red racks, and left slat addresses the six pins of the blue rack.  If you were physically positioning the 24-pin boxes near the racks they serve, the addressing scheme of Figure 2 would probably be preferable to that of Figure 1. Figure 2 also reveals how virtual slats work by showing the script rows in the lower right window that correspond to the circled red racks on the left, and by showing the exported script file that the firing system consumes in the upper right.  The script window uses three-part addresses to represent the virtual slats.  The first 24 pins are 01-A-01 to 01-A-24, and the second 24 pins are 01-B-01 to 01-B-24.  The "A" and the "B" are the virtual slats. Since the concept of virtual slats exists only in Finale 3D, the software needs to convert the three part virtual slat addresses to the native address format that the firing system expects in the script that it imports.  The conversion is no more than a simple addition, as you can see in the exported firing system script in the upper right window.  Address 01-B-01 in the script window below corresponds to 01-25 in the exported firing system script above.   Figure 3 – To use virtual slats, create a custom module with three part addresses.   To use virtual slats, you need to create a custom module with three part addresses from the menu "Addressing > Addressing settings > Set custom module specifications..." menu item.  The rail address template of #99-B-#24 means that there are 99 possible modules beginning with 1, numbered; there are two slats designated by letters A and B, and each slat has 24 pins beginning with 1.  For more information on custom modules, see custom modules.   Figure 4 – In paragraph 3 of the addressing dialog, add the constraint that each slat is restricted to a single rack cluster.   Creating the custom module definition is just the starting point that gives you the ability to control how addresses are allocated at the level of granularity of the slats instead of modules.  If you want to avoid the long e-matches stretching between the clusters of racks shown in Figure 1, then add the constraint in paragraph 3 of the addressing dialog that slats are restricted to a single "Rack Cluster".  Addressing with the rack cluster constraint on slats produces the Figure 2 result.  Please note also that in the addressing dialog you need to select "Custom Module" in paragraph 1 to use your virtual slats addressing scheme.  

As described here, the order in which script rows are assigned firing system addresses and racks is based on a sequence of sort terms like "Position > Angle", meaning that the rows are sorted first by position, and then ties are broken by angle.  Additional terms added to the end of the sequence are successive tie breakers. "Position > Angle > Part Number", for example, break ties for effects in the same position with the same angle according to their part number. There are circumstances in which it is useful to sort different kinds of effects differently, such as sorting cakes differently from items that go into mortars.  If the items being sorted differently are in different positions, then you can use addressing blueprints assigned to the positions to define different sort criteria for the different effects, but if the items are in the same position then blueprints don't provide a solution. The only way to create a conditional sort for items in the same position is to represent the conditional sort somehow in the list of sort terms.  Toward this end, Finale 3D includes thirty or so special sort terms designed expressly for representing basic conditional sorts. Consider a simple example of sorting cakes differently from non-cakes.  The tube size in cakes generally doesn't factor into the desired sort order for cakes since it doesn't affect the wiring or racking, but for non-cakes the tube size may be integral to the arrangement of racks and wiring.  Thus if a position contains cakes and non-cakes, it is reasonable to want a conditional sort that takes into account size for non-cakes but ignores size for cakes so that cakes can be sorted by other criteria.  The goal and the solution are shown in Table 1.   Table 1 – A conditional sort that ignores size for cakes If cake Part Number If non-cake Size > Part Number Conditional sort Cakes Last > Size -- Non-Cakes > Part Number   All conditional sorts should contain a term that splits apart the groups of effects that are sorted differently by sorting one group ahead of the other.  In the example of Table 1, the term "Cakes Last" splits apart the cakes from non-cakes by putting the non-cakes first.  The next term, "Size -- Non-Cakes", is a tie breaker for items that compare equally with respect to "Cakes Last".  The ties may be comparisons of cake to cake, or non-cake to non-cake, but any comparison of cake to non-cake is not a tie -- the cakes are last.  "Size -- Non-Cakes" applies no preference to cakes; it only sorts non-cakes against each other according to their size.  Thus "Size -- Non-Cakes" operates as a tie breaker for the non-cakes and leaves the cakes as they are.  The final term in this conditional sort, "Part Number", applies to everything, so it operates as a tie breaker for non-cakes of the same size, and a tie breaker for cakes of any size.   Table 2 – A conditional sort that applies different sort terms for cakes and single-shots If cake Rack Type > Part Number If single-shot Angle > Size > Part Number Conditional sort Cakes First > Angle -- Non-Cake > Size -- Non-Cake > Rack Type -- Cake > Part Number   The example of Table 2 applies to a position that includes cakes and single-shots.  Like the previous example, the goal is to exclude size from the cake comparisons, but in this example the goal is also to exclude angle from the cakes and to include rack type for the cakes only.  The scenario underlying this example is a position with two kinds of cakes -- slice cakes and box cakes.  The designer wants to put the slice cakes in cake racks but has chosen to ignore racks for the box cakes since they just sit on the ground.  The designer uses the "Rack Type" field of the script to distinguish the slice cakes from the box cakes (for example, giving the slice cakes a rack type of the word "slice" while leaving the rack type of the box cakes blank). The technique and mechanics of this second example are the same as the first:  Begin by separating the two types of effects that sort differently ("Cakes First"); then use variations of sort terms that apply to one group of effects or the other group for the sort terms that the groups do not have in common.  You can see how the conditional sort of Table 2 implements the goals of the two lines above it. The technique illustrated by Table 1 and Table 2 is capable of representing basic conditional sorts involving the common sort terms that tend to apply to a subset of effect types.  To see what is possible, please refer to the full list of terms here.    

The addressing dialogs present a sequence of sort fields that define the order in which script rows are assigned firing system addresses and racks.  The first field is the primary term.  The next field is a tie breaker for rows that compare equally as far as the first term.  The third field is a tie breaker for the second, and so on.   It is common to begin the sort sequence with "Position" so firing system addresses are assigned in the alphabetical order of the positions.  As an example, the sequence "Position > Angle" sorts first by position, and then within a position sorts rack and tube assignments in a left to right arrangement to prevent tubes from aiming toward each other. Many other addressing sort sequences are possible (about 700,000,000,000,000), ranging from simple sequences of a single term like "Event time", which just sorts the rows chronologically, to complex sequences that sort different kinds of effects differently, like sorting mortar items by size and cakes by rack type. Most of the sort terms are just fields from the script table but some are "special" in that they compare in an unusual way or they are derived or dynamically recalculated.  The full set of terms are listed in Table 1, including an indication for "special" or "dynamic".  The dynamic terms are those that are recalculated after every assignment to take into consideration what the previous assignment was and what racks remain available. To understand the mechanics of the sort terms, it is helpful to keep in mind how the addressing operation works: The addressing operation begins with the first script row in the sorted list, assigns it the next available address and rack that are compatible, then moves on to the next row in the list after re-sorting it, assigns the next row the next available address and rack that are compatible, and so on.   Table 1 – Sort terms in the addressing dialogs Sort Term Special Dynamic Meaning Angle Yes Sorts items by their angle; comparing front to back angle first, then left to right. Angles First Yes Angled items first (any angle), then straight-up items. Angles Last Yes Straight up items first; then angled items. Cakes First Yes Cakes first (according to Type); then other items with no preference between them. Cakes Last Yes Cakes last; other items first with no preference between them. Candles First Yes Candles first; then other items with no preference between them. Chain Reference Simple comparison. Chains First Yes Chain rows before non-chain rows. Chains Last Yes Non-chain rows before chain rows. Custom Numeric Field A user-defined numeric field available for you to make your own custom sort criterion. Custom Part Field Simple comparison. Custom Position Field Simple comparison. Custom Script Field Simple comparison. Description Simple comparison. Event Time Simple comparison. Fan Chains First Sorts chains whose shells are not all at the same angle before other effects. Fan Chains Last Sorts chains whose shells are not all at the same angle after other effects. Fan Flights First Sorts flights whose shells are not all at the same angle before other effects; a flight is a group of effects with the same event time and same position. Fan Flights Last Sorts flights whose shells are not all at the same angle after other effects; a flight is a group of effects with the same event time and same position. Has Rack Type Part Number Yes Gives priority to any effects whose Rack Type matches the Part Number of a rack in any of the available collections.  The Rack Type field can contain a user-defined term (a word or number) as a matching criterion to match effects and racks with the same Rack Type; or the Rack Type field can contain the Part Number of a specific rack to restrict the effect to that type of rack specifically.  This sort criterion only prioritizes effects with Part Numbers in their Rack Type fields. Hazard Simple comparison. Manufacturer Simple comparison. Matches Any Rack Yes Yes Gives priority to effects that are compatible with at least one remaining available tube, taking into consideration the effect's angle, size, and rack type.  This field is useful to demote unracked items to the end of the list, such as, for example, to use the last pins of a module for cakes when not using cake racks. Mortar Items First Yes Gives priority to items that are compatible with mortar racks (shells, mines, comets) over all other items. Most Horizontal Tilt Yes Sorts by angle delta from up in any direction (absolute value of angle delta); blank angle value is equivalent to zero. This sort term and its single-shot specific variation are useful for sorting the most outward leaning single-shot effects first, for fan row racks that have different angle range constraints on the outer edge holders than the interior holders (interior holders can't tilt as far because they physically collide with their neighbors). Sorted most outwardly leaning first, the effects that need the outer edge holders get the first chance at allocating them. Most Horizontal Tilt -- Single-shot Yes Single-shots first, in order of most horizontal tilt (see above); then non-single-shot effects in their original order.  This is the best sort term for ensuring the holders on the edges of fan row racks get allocated by the effects that need to aim more severely than the interior holders are capable of. Next Tube In Rack Yes Yes Gives priority to items that are compatible (angle, size, and rack type) with the tube that immediately follows the tube allocated in the previous assignment, according to the tube loading order of the rack; assigns no priority if the previous assignment assigned the last tube in a rack.   This sort term is useful in combination with and immediately following "Same Rack" as in "Same Rack > Next Tube In Rack" for encouraging sequential pin numbers in rack tubes with pre-assigned angles. Non-Cakes First Yes Non-cake rows before cake rows. Notes Simple comparison. Notes 2 Simple comparison. Notes 3 Simple comparison. Pairs First Yes Gives priority to pairs -- items for which the flight length is exactly two (see flight length) Pairs Last Yes Gives priority to non-pairs -- items for which the flight length is anything other than two (see flight length) Longest Flights First Yes Sorts according to flight length, longest first.  The flight length is the number of effects with the same event time, at the same position. Part Number Simple comparison. Pitch Simple comparison.  Pitch is the forward/back angle of the effect. Position Simple comparison. Rack Number Sorts items based on the racks they fit into, enabling you to do Addressing based on layout of racks.  Generally speaking, this sort criterion causes racks to be filled in order, by their rack number.  There are circumstances in which that will not be the case, based on the actual definition of this sort term. The actual definition of this sort term is: this term gives highest priority to items that "fit" in the same rack as the first effect of the last assignment (chains and flights may have multiple shells in different racks), next highest priority to items that fit in the same rack as the last effect of the last assignment (which may matter for chains),  next highest priority to items that fit in the first non-full rack after the last effect of the last assignment (first according to rack number), and finally next highest priority to items that fit in the lowest numbered rack in the position. The term "Fit" means that a) the item's properties like Size and Type and Rack Type, taking into consideration sleeving and Rack Type Part Numbers, are compatible with the rack's definition, and b) if the item is a chain and the pin addressing constraints include Rack (which forces chains to fit in single racks) then the number of shells in the chain does not exceed the number of remaining unused tubes in the rack.  "Fit" does not take into consideration any other addressing constraints from the addressing dialog or blueprint.  "Fit" does not take into consideration pre-wired pin constraints.  Thus it is possible for the Rack Number sorting criterion to give priority to an item that fits into the next rack by this definition of "fit" but that ultimately gets assigned to a different rack on account of addressing constraints. If none of the items in a position fit in the position's lowest numbered rack, then the Rack Number sort criterion for the position offers no priority to any of the items for the first assignment in the position; and thus the first assigned item may be in any rack, not necessarily the lowest numbered rack for which an item fits. Rack Type Simple comparison. Rack Type -- Cake Yes Cake items first in order of Rack Type by simple comparison; then non-cake items in original order. Rack Type -- Candle Yes Candle items first in order of Rack Type by simple comparison; then non-candle items in original order. Rack Type -- Mortar Item Yes Mortar items (shells, mines, comets) first in order of Rack Type by simple comparison; then non-cake items in original order. Rack Type -- Single-Shot Yes Single-shot items first in order of Rack Type by simple comparison; then non-single-shot items in original order. Reverse Angle Yes Reverse of the angle comparison. Reverse Size Yes Reverse of the size comparison. Reverse Size -- Cake Yes Cake items first in reverse order by size comparison; then non-cake items in original order. Reverse Size -- Candle Yes Candle items first in reverse order by size comparison; then non-candle items in original order. Reverse Size -- Mortar Item Yes Mortar items (shells, mines, comets) first in reverse order by size comparison; then non-mortar items in original order. Reverse Size -- Non-Cake Yes Non-cake items first in reverse order by size comparison; then cake items in original order. Reverse Size -- Single-Shot Yes Single-shot items first in reverse order by size comparison; then non-single-shot items in original order. Reverse Tilt Yes Reverse of the tilt comparison (angle difference from up). Reverse Tilt -- Cake Yes Cake items first in reverse order by tilt comparison; then non-cake items in original order. Reverse Tilt -- Candle Yes Candle items first in reverse order by tilt comparison; then non-candle items in original order. Reverse Tilt -- Mortar Item Yes Mortar items (shells, mines, comets) first in reverse order by tilt comparison; then non-mortar items in original order. Reverse Tilt --Non-Cake Yes Non-cake items first in reverse order by tilt comparison; then cake items in original order. Reverse Tilt -- Single-Shot Yes Single-shot items first in reverse order by tilt comparison; then non-single-shot items in original order. Roll Simple comparison.  Roll is the left/right angle of the effect; blank value is equivalent to zero. Same Rack Yes Yes Gives priority to items that "fit" in the rack of the tube allocated in the previous assignment; obviously assigns no priority if the previous assignment assigned the last tube in a rack (because the rack would have no remaining available tubes). The term "Fit" means that a) the item's properties like Size and Type and Rack Type, taking into consideration sleeving and Rack Type Part Numbers, are compatible with the rack's definition, and b) if the item is a chain and the pin addressing constraints include Rack (which forces chains to fit in single racks) then the number of shells in the chain does not exceed the number of remaining unused tubes in the rack. "Fit" does not take into consideration any other addressing constraints from the addressing dialog or blueprint.  "Fit" does not take into consideration pre-wired pin constraints.  Thus it is possible for the Same Rack sorting criterion to give priority to an item that fits into a rack by this definition of "fit" but that ultimately gets assigned to a different rack on account of addressing constraints. The Same Rack sort term is useful in combination with and immediately before "Same Row In Rack" or "Next Tube In Rack" as in "Same Rack > Next Tube In Rack" for encouraging sequential pin numbers in rack tubes or rack row tubes with pre-assigned angles. The Same Rack sort term can also be used in front of "Chains First" as in "Same Rack > Chains First" to fill racks with as many chains as can fit in each rack and then to fill the remaining tubes in the rack with single shells before going forth to fill chains in the next racks, resulting in naturally incrementing pin numbers for the chains and shells in the racks while at the same time ensuring the single shells don't fill up a rack that would be better suited for chains. Same Row In Rack Yes Yes Gives priority to items that are compatible (angle, size, and rack type) with any remaining tube in the rack row of the tube allocated in the previous assignment; obviously assigns no priority if the previous assignment assigned the last tube in a rack row.   This sort term is useful in combination with and immediately following "Same Rack" for encouraging sequential pin numbers in rack tubes or rack row tubes with pre-assigned angles. Single-Shots First Yes Single-shot rows before non-single-shot rows. Size Simple comparison. Size -- Cake Yes Cake items first in order by size comparison; then non-cake items in original order. Size -- Candle Yes Candle items first in order by size comparison; then non-candle items in original order. Size -- Mortar Item Yes Mortar items (shells, mines, comets) first in order by size comparison; then non-mortar items in original order. Size -- Non-Cake Yes Non-cake items first in order by size comparison; then cake items in original order. Size -- Single-Shot Yes Single-shot items first in order by size comparison; then non-single-shot items in original order. Size >= 35MM -- Single-Shot Yes Single-shot items of size >= 35MM first, in their original order; then other single-shot items in their original order; then non-single-shot items in their original order.  This family of sort terms is useful when a position contains single-shot racks with different holder sizes.  If the larger holders can house both large and small effects, but the smaller holders can house only the smaller effects, then it can be important to sort larger effects first so the larger holders don't get used up by the smaller effects. Size >= 40MM -- Single-Shot Yes Single-shot items of size >= 40MM first, in their original order; then other single-shot items in their original order; then non-single-shot items in their original order. Size >= 45MM -- Single-Shot Yes Single-shot items of size >= 45MM first, in their original order; then other single-shot items in their original order; then non-single-shot items in their original order. Size >= 50MM -- Single-Shot Yes Single-shot items of size >= 50MM first, in their original order; then other single-shot items in their original order; then non-single-shot items in their original order. Size >= 55MM -- Single-Shot Yes Single-shot items of size >= 55MM first, in their original order; then other single-shot items in their original order; then non-single-shot items in their original order. Size Or Sleeve Comparison of the items' size or sleeve (if present). Storage Location Simple comparison. Tilt Simple comparison (signed angle difference from up); blank value is equivalent to zero. Tilt -- Cake Yes Cake items first by tilt comparison; then non-cake items in original order. Tilt -- Candle Yes Candle items first by tilt comparison; then non-candle items in original order. Tilt -- Mortar Item Yes Mortar items first by tilt comparison; then non-mortar items in original order. Tilt -- Non-Cake Yes Non-cake items first by tilt comparison; then cake items in original order. Tilt -- Single-Shot Yes Single-shot items first by tilt comparison; then non-single-shot items in original order. Tilt > 50° Yes Items with tilt magnitude > 50° first, in their original order; then other items in their original order. Tilt > 50° -- Single-Shot Yes Single-shot items with tilt magnitude > 50° first, in their original order; then other single-shot items in their original order; then non-single-shot items in their original order. Track Simple comparison. Tubes Simple comparison of the Tubes field.  For racks, the Tubes field is part of the specification, but for effects the Tubes field can mean whatever the user wants it to mean, like the Custom Numeric Field. Type Simple comparison.    

Large racks with multiple rows of tubes are easier to set up if there is some rhyme and reason to the arrangement of firing system pin numbers in the rack.  For adjustable tube angle racks, the easiest way to guarantee a sensible layout of tubes is just to check the checkbox on the addressing dialog, "Re-arrange tubes of adjustable angle racks to avoid collisions," which automatically provides an optimized layout with no tube angle collisions (see instructions here).  For non-adjustable angle racks or if you have a specific layout in mind, the tube loading order option in the rack definition enables you to define whether the pin numbers progress left-to-right-top-to-bottom, or in other arrangements.  In combination with the addressing sort criteria that you specify when addressing the show, the tube loading order gives you a great degree of control over the pin arrangement.    Figure 1 – Fan row rack with three rows of five tubes each.   The fan row rack of Figure 1 is an illustrative example.  If you configure this rack as an adjustable fan row rack (see here), whose tube angles are defined according to the needs of the show, then the tube loading order will control whether the rack ends up with fan-like rows (as shown in Figure 1) or rows with mostly the same angle tubes (imagine if the first three tubes in Row 1 of Figure 1 aimed the same direction instead of the first tubes of the rows having the same direction).   Figure 2 – Options for tube loading order   The tube loading order option is in the rack specification, as shown in Figure 2.  Taking the 15-tube rack of Figure 1 as an example, the next set of figures illustrate the different tube loading order options for a show with 13 effects, leaving two tubes unused.  Bear in mind as you look at these diagrams that the rows are defined in Figure 2 in the 5-tube direction, not crossways in the 3-tube direction.  The racks are shown rotated 90° counter-clockwise to make the the rows align left/right with the audience.  Please see Rack “row” and standard orientation if you have any question as to the orientation of the rows.  The Rack structure selector of Figure 2 is: "Single-shot rack, adjustable fan angles of tubes within each row".   Figure 3 – By rows, left to right   The rack rows in the identity orientation are vertical in the top-down view, so the fan row racks are generally added to the show rotated 90 degrees counter-clockwise to make degrees of freedom of the tube angles tilt left/right instead of forward/back.  The first rows in the identity orientation begins with the first tube in the upper left, counting down vertically.  So if you rotate the rack counter-clockwise 90 degrees from the identity orientation, the first tube becomes the lower left, and the progress goes to the right, which is what you see in Figure 3.   Figure 4 – Across rows, left to right   Figure 4 shows the "Across rows, left to right" loading order, which begins with the same tube but progresses to the right in the identity orientation, and equivalently progress upward across the 5-tube rows in top-down view when rotated counter-clockwise 90 degrees.   Figure 5 – By rows, right to left   If you want to begin in the upper left in the rotated orientation, then Figure 5 and Figure 6 are the right options..   Figure 6 – Across rows, right to left   Referring back to the rack definition dialog in Figure 2, the "Alternating row tube loading order" checkbox in the upper right indicates each that alternating rows in the tube sequence will count in opposite directions, snaking the pin numbers back and forth (see here).  If you think this back and forth option will give you cleaner wiring and you are otherwise ambivalent on the choice of "Across rows" or "By rows" loading orders, you should go with the "Across rows" options, at least for adjustable fan row racks.  Why?  Because if your addressing sort criteria include "Angle" then the increasing pin numbers will represent increasing angles (toward the right).  Thus the rows of Figure 6 and of Figure 7 would all be nicely fan-like.  But if you checked "Alternating row tube loading order" for the "By rows" option of Figure 5, the second row would begin with pin 6 on the right, but pin 6 would be the most left-leaning effect in the row.  Thus the second row would be almost certain to have colliding tubes that aim into each other!   Figure 7 – Across rows, right to left, alternating row tube loading order