To create and export a script for the Pirotex 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 Pirotex firing system   The Pirotex script is a text file that supports 32, 64, 128, and 256-pin modules, and 10-pin slats (AKM-10).  The pins on the modules themselves are triggered by the channel number associated with the pin, which is just the pin number.  The pins on the slats fire in order from first to last, triggered by successive triggers of the channel number on the module associated with the slat.    Each row of the script specifies only a module number and channel number as the firing address.  If a slat is attached to the channel number, then the row triggers the next unfired pin on the slat.  If no slat is attached to the channel number, then the row triggers any effects that are wired directly to the pin on the module.   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text .txt UTF-8 Tab CRLF The script contains rows for the firing events, i.e., unique combinations of module, channel, and ignition-time.  Multiple effects can be combined on a single cue. The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Sort order of rows Rows sorted ascending first by Event Time. What rows represent Rows represent firing events, i.e., unique module-channel-ignition-time events.  If multiple effects are triggered on the same cue, the effects are combined in name field, but the row is still just one row. Special characters If a field contains a double-quote character (“), then the field will be enclosed in “ on both ends, and any internal “ characters will be doubled up, following the Excel quoting convention. Minimum separation between cues None Multi-hit pins Supported in the script format and with manual addressing in Finale 3D, for non-pyro effects like flames and relays that can be triggered multiple times.  Finale 3D handles multi-hit pins in the Pirotex exporter the same as it handles single-hit pins — whatever pin address is in the script row in Finale 3D will be copied to the exported script row for Pirotex, whether or not the pin address is unique.  The standard pyro addressing functions in Finale 3D assign pins sequentially, so it may be easiest to address multi-hit pins in Finale 3D by editing the script table by hand and then locking the edited rows so the show can be re-addressed for pyro without affecting them. Slats The pins on the Pirotex AKM-10 slats fire in order from first to last, triggered by successive triggers of the channel number on the module associated with the slat.    Each row of the script specifies only a module number and channel number as the firing address.  If a slat is attached to the channel number, then the row triggers the next unfired pin on the slat.  If no slat is attached to the channel number, then the row triggers any effects that are wired directly to the pin on the module. It is easy to assign firing system addresses automatically in Finale 3D for a Pirotex show that uses only pins on the modules, or a show that uses only pins on the slats.  It is also not so hard to assign addresses automatically for a show that uses pins on both modules and slats, but only if the slats are connected to different modules. If the show uses pins on modules and on slats connected to the same modules, then you have to assign firing system addresses manually. If your show uses only the pins on the modules themselves, no slats, then simply address the show using any of Finale 3D’s addressing functions, and choose the “Pirotex 32 Pin Module” module type to be used throughout (or choose 64 or 128 or 256 pin). If your show uses only the pins on the slats, ignoring the pins on the modules, then simply address the show using any of the Finale 3D’s addressing functions, and choose “Pirotex AKM-10” module type (slats). If your show uses the pins on the modules at some positions, and uses AKM-10 slats at other positions but does not use any pins on modules to which the slats are attached, then select the positions at which you want to use the modules’ pins, right click on them and do “Edit Properties”.  Set their module type to “Pirotex 32 Pin Module” (or other 64 or 128 or 256). Select the other positions, right click on them and set their module type to “Pirotex AKM-10”. Then address the show using any of the addressing functions. Slats connected in series AKM-10 slats connected in series act as a single slat with all the pins combined (gaps from unused pins are ignored).  The pins are triggered by a single channel for the whole series, which means the slat numbers assigned to the individual slats by the addressing function are NOT the channel numbers for series. The Custom Position Field, which you can set by editing position properties, is a “channel override” for the Pirotex exporter.  It enables you to specify a single channel number to use for all firing rows at the position: whatever channel would have been exported (the pin number for pins on the module, or the slat number for pins on the slat) will be overwritten by the value of Custom Position Field. EXAMPLE: Consider three positions with 16 shots per position, addressed for AKM-10 slats in position order.  The first position would have slat 1 and 2; the second would have 3 and 4; the third would have 5 and 6. If the user wants to attach 1 and 2 in series and assign them to channel 1, the user sets the Custom Position Field for position 1 to 1.  Similarly, he sets the Custom Position Field for position 2 to 2; and 3 to 3. RULE: For any positions with AKM-10s (in series or not), you must sort shots at the positions first by event time (e.g., sorting by “Position then Event Time”).  If the AKM-10s are in series you must also avoid any slat constraints that could result in pin numbers across the series being non-chronological. The rule for slat constraints on positions with AKM-10s in series is tricky.  In general you cannot safely constrain slats to any effect property (size, part number, etc.) with AKM-10s in series, because that could result in non-chronological shots between the slats.  You can constrain slats to the same rack or rack cluster if all the racks at the position are equivalently compatible with the shots at the position (e.g., all tubes are the same size). This constraint, which is useful to avoid e-matches running between racks or rack clusters, is the only slat constraint that is prudent to use with AKM-10s in series if you use the automatic addressing functions.  If you use the fill-down addressing method, you can use all constraints if you uncheck the “Backfilling allowed” box in the fill-down dialog. The Pirotex script has no header, just a list of rows corresponding to the firing events.  Each row has four fields, defined as follows:   Table 3 – Specifications of script fields Field name Description Event Time Time in the format H:MM:SS:FFF from the beginning of the show (millisecond resolution) Module Number Module number, beginning with 1. Channel Number If the row refers to a terminal on a module, then this field is the pin number, beginning with 1, up to 32, 64, 128, or 256, depending on the module type.  If the row refers to a terminal on a slat (i.e., the AKM-10 slat), then this field is the channel number of the slat or slats connected in series. The pins on a slat are triggered in sequence by successive triggers of the slat’s channel number. Effect Name The effect name. The example script below is from a show with two positions.  One position has 16 shots, a tenth second apart, shot from two AKM-10 slats on channel 1 and 2 of module 10.  The first 10 sequential shots all have module 10, channel 1 in the script; the next 6 sequential shots all have module 10, channel 2.  These are the first 16 rows in the script. The second position has 2 shots, a tenth second apart, shot using the pins directly on module 20.  In the script, these two rows have module 20, and channel 1 and 2 corresponding to pins 1 and 2 on the module itself.   0:00:02.800 10 1 Red Chrysanthemum 0:00:02.900 10 1 Red Chrysanthemum 0:00:03.000 10 1 Red Chrysanthemum 0:00:03.100 10 1 Red Chrysanthemum 0:00:03.200 10 1 Red Chrysanthemum 0:00:03.300 10 1 Red Chrysanthemum 0:00:03.400 10 1 Red Chrysanthemum 0:00:03.500 10 1 Red Chrysanthemum 0:00:03.600 10 1 Red Chrysanthemum 0:00:03.700 10 1 Red Chrysanthemum 0:00:03.800 10 2 Red Chrysanthemum 0:00:03.900 10 2 Red Chrysanthemum 0:00:04.000 10 2 Red Chrysanthemum 0:00:04.100 10 2 Red Chrysanthemum 0:00:04.200 10 2 Red Chrysanthemum 0:00:04.300 10 2 Red Chrysanthemum 0:00:16.116 20 1 Blue Chrysanthemum 0:00:16.216 20 2 Blue Chrysanthemum Figure 1 – Example Pirotex script

To create and export a script for the COBRA firing system, please follow these three steps: Address the show (“Addressing > Address show”). Export the script to a USB thumb drive (“File > Export > Export firing system script file…“). Load the script by inserting the USB thumb drive into the 18R2 remote. Step 2 creates the script file, which is a standard format CSV file with a “CSV” extension.  The file format details are described below in this section.   Figure 1 – Cobra firing system   Cobra modules have 6, 18, 36, or 72 pins (cues), but as far as addresses are concerned the modules with more than 18 pins are just two or four 18-pin modules combined, with each of the 18-pin modules having a separately assignable module number (channel number).  If you use 36 or 72 pin modules, simply treat them as multiple 18-pin modules stuck together, and assign their separate module numbers to whatever is needed at their physical locations.  If you use 6-pin modules, take care to avoid assigning pins above 6 or create a custom module with a 6-pin limit.   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text .csv ASCII Comma CRLF The script contains rows for the firing events, i.e., unique combinations of module, pin, and ignition-time. Multiple effects can be combined on a single cue. The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Script formats for different Cobra firmware versions Finale 3D can export script files formatted for the following COBRA firmware versions: v3.X v4.X, v5.0.X v5.1.X v6.X v7.0 v7.2 and later COBRA v3.0 and v4.0 scripts have 1/10th of a second resolution; later versions have 1/100th of a second resolution.  Beginning with COBRA v6.0, the script supports launch position coordinates, definable pulse time and embedded part numbers. COBRA v7.0 scripts introduce track labels (see below), disable groups (see below). COBRA v7.2 scripts introduce the “DMX Ramp-From Value” field (see below). What rows represent Rows represent firing events, i.e., unique module-pin-ignition-time events. If multiple effects are triggered on the same cue, the effects are combined in name field, but the row is still just one row. Sort order of rows Event rows in each section of the script are sorted ascending first by Event Time. Script comments Empty cues in Finale 3D that have text in the Note field are included in exported Cobra scripts as script comment rows.  The format of the script comment rows for Version 6 or later includes the Event Time field and the Name field only, as shown in the middle line of this example: 0,1,,0,audiobox.mp3,cobra,,,, 00:00:02.16s,,,THIS IS A SCRIPT COMMENT,,,,,,, 00:00:02.76s,channel 1,cue 1,Red Chrysanthemum,,,,,,, Script comment rows for Version 5 and earlier are simply pound-sign comment rows, as in: 0,1,,0,audiobox.mp3,cobra,,,, #THIS IS A SCRIPT COMMENT 00:00:02.76s,channel 1,cue 1,Red Chrysanthemum Script comment rows in the Version 6 format will appear in Cobra Show Creator and in the Cobra Control Panel. Special characters To avoid the need for an escaping convention, Finale 3D filters out comma, semicolon, double-quote, backslash, and all control characters from the exported script. The Cobra controller implements the Excel escaping convention, but Finale 3D filters the characters anyway to avoid types of errors that are common when users import and export from Excel and text editors. Types of scripts Cobra firing systems support four types of scripts for different firing methods, which you can select from the Export Options dialog when exporting a script: 1) “Separate Scripts By Tracks” 2) “Step By Tracks” 3) “Step By Events” 4) “Standard Script” The Standard Script method is a single script that executes as a complete show when initiated or when sequenced with timecode.  Pyromusicals use this script type because a complete show can aligned with the music in a soundtrack. The Separate Scripts By Tracks method splits the script into multiple scripts that are triggered on demand by pressing the corresponding cue button on the Cobra controller. The Step By Tracks method is similar, but advances through the tracks of the show sequentially with the step button on the controller, instead of by random access. The Step By Events method advances one event at a time sequentially with the step button.  Examples of all four script formats are provided in Table 4.See semi-automatic-firing for further instructions. Tracks The “Separate Scripts By Tracks” and “Step By Tracks” firing methods use the Track property in Finale 3D script rows to indicate the section of the show to which the row belongs. For Separate Scripts By Tracks the Track also indicates the button on the Cobra controller that triggers the section, which is in the Track value itself, a number 1-18 (please unhide the Track property in the script to use this feature). In Finale 3D, the Track field in the script table is hidden by default; unhide it from the blue gear menu. In the Cobra script file, sections are listed sequentially with a comment row and header row above the event rows, e.g., #Track 1,,,,,,,,,, 0,1,,0,audiobox.mp3,Opening,,,,timecode1, The number in the Track field in the Finale 3D script is the number in the #Track comment row, and also the second field (Trigger Button) in the header row.  The sixth field in the header row for the script (“Opening” in the example above), is a track label. The rows in each section of a semi-automatic script have time values relative to the first event in the section, which is always time zero. In the Finale 3D script, please arrange the track sections in order, with no interwoven or overlapping events. Track labels Track labels were introduced in COBRA firmware V7.0 for “Separate Scripts By Tracks” shows to provide a readable label or note on the remote for the track/script.  In Finale 3D, the Track field holds the track number and the track label together, as in “01 Opening” or “02 Middle Section”.  The track number is the first number contained in the string, e.g., the number 1 in “01 Opening” or “Opening 01”.  The track label is the string itself after skipping over any leading number in the string and trimming whitespace.  For example, the track label of “01 Opening” is “Opening”; the track label of “Opening 01” is the same “Opening 01” because the string doesn’t begin with the number. The best practice for representing track numbers and labels in the Track field in Finale 3D is to use a two digit number padded with a leading zero if necessary, followed by the track label.  The reason for the two digits and for putting the number first is to make it possible to sort the script window in Finale 3D by the Track column numerically. Step By Events “Step By Event” scripts advance through the “Step Cues” manually as you press the STEP button. Each Step Cue consists of one or more events that are logically triggered together. For example, a pair of shells ignited at the same time are logically triggered together even if they are ignited by different pins or modules. A stack of different size shells ignited at the same time — and thus generally breaking at different times — are also part of the Step Cue. The concept of events being logically triggered together also extends to events with the same effect times.  A stack of different size shells ignited at different times but breaking at the same time are also part of the same Step Cue, because that is what you would expect. If events in a Step Cue have different ignition times, the Step Cue triggers the first immediately and incorporates a delay in the later events to preserve their relative ignition times. A stack of different size shells breaking at the same time thus generally fires the largest shell immediately and the smaller shells after delays that cause them to break at the same time. DMX events may also be included in Step Cues, on their own or combined with pyro events. Since a DMX effect represented by one row in the script table may require multiple DMX events in the exported script to control multiple DMX channels, all the DMX events associated with a row of the script table are necessarily part of the same Step Cue. In some cases, such as a DMX fixture with a color wheel or moving head, some of the DMX events associated with the effect must occur in advance of the visual appearance in order to turn the color wheel or move the head to the correct angle before turning on the fixture effect.  Since the wheel turning or head moving can’t begin until the Step Cue has been triggered, the fixture effect may not be ready to turn on immediately, which manifests in a delay between when you press the STEP button and when the effect visually appears.  Please see DMX setup events — preparing channels before the effect begins for more details. Alternates Cobra scripts provide for listing “Alternate1” and “Alternate2” events at the end of the script, and binding the events to buttons that can be pressed to trigger the events during or after the script.  To use this function in Finale 3D, unhide the “Alternate” column in the script table window, and put the value “1” into script rows that you want to be “Alternate1” events; and the value “2” into script rows that you want to be “Alternate2” events.  Finale 3D will include these events at the end of the exported script, and optionally double-list them in the body of the script depending on your choices in the Export Options dialog (See Table 3). Disable groups COBRA v7.0 and higher firmware recognizes the “Hazard” field of Finale 3D, which is exported as a text field identifying a class of events that can be disabled on the fly based on conditions during the show. Pulse Time COBRA v6.0 and higher firmware supports a user-defined pulse duration for which cue is to be energized. The pulse duration values in the exported script come from the durations of flames, lights, and other special effects. For more details on pulse duration, see Why is ‘Type’ so important? What depends on it? Multi-hit pins Used for non-pyro effects like flames and relays that can be triggered multiple times. Finale 3D handles multi-hit pins in the Cobra exporter the same as it handles single-hit pins — whatever pin address is in the script row in Finale 3D will be copied to the exported script row for Cobra, whether or not the pin address is unique. The standard pyro addressing functions in Finale 3D assign pins sequentially, so it may be easiest to address multi-hit pins in Finale 3D by editing the script table by hand and then locking the edited rows so the show can be re-addressed for pyro without affecting them. DMX COBRA v6.0 and higher firmware with 36M and 72M modules supports DMX output for separate or shared DMX universes on each module. DMX Safety Channels Across Tracks The “Separate Scripts By Tracks” script type requires safety channel events for all relevant fixtures at the beginning of each track; the other script types only require safety channel events at the beginning of the show, applying to the full show. 1) “Separate Scripts By Tracks”: All DMX channels including safety channels reset to 0 at the beginning of each track; every track requires safety channel events for all fixtures. 2) “Step By Tracks”: All DMX channels including safety channels are unaffected by track changes; safety channel events for fixtures in the first track apply for the entire show. 3) “Step By Events”: Safety channel events for fixtures apply for the entire show. 4) “Standard Script”: Safety channel events for fixtures apply for the entire show. DMX Ramp-From Value COBRA v7.2 and above support the “DMX Ramp-From Value” field which specifies the interpolation start value for a DMX channel.  This feature supports fades and color blends for light fixtures, and more controllable movement for moving head fixtures. Track DMX Latency Option (Advanced option) To reduce the delay from when you press the trigger button and when a track begins you may want to limit the “setup time” for DMX events.  Events for moving head fixtures and color wheel fixtures set the angle or color wheel parameter prior to the effect by as much as a 1000ms to ensure the angle or color wheel is in the proper position at the time the effect becomes visible.  If such an event is the first event in a track, then the track’s start time will be 1000ms before the effect becomes visible, which is a long latency if you want the track to begin immediately when you press the button! If your show is sensitive to this latency, you can set the Per-Show Setting maxInitialDmxSetupDelayMs to whatever maximum number of milliseconds you are willing to allow the fixture for its setup time for any DMX events.  You can set the setting to any integer, but 100 is the recommended minimum value to avoid potential problems with fixtures that require channels to be set in a specific order. When you export a firing script for Cobra, Finale 3D presents an “Export Options” dialog with options that go into the header of the exported script or affect the format.  The choices are shown in Table 3.   Table 3 – Export options Option name Description Version Choose the script format that matches your firmware version, v3.X – v7.X.  The version affects the number of columns in the exported script, the time resolution, and various capabilities.  Version v6.0 is the first version to support DMX. Script Type Choose one of the four script types: Standard Script, Step By Events, Separate Scripts By Tracks, and Step By Tracks. Script Filename Firmware v5.0.X or lower: Filename must be exactly “cobra.csv”. Firmware v5.1.X: Custom filenames allowed up to 42 characters including “.csv”. Firmware v6.X or higher: Custom filenames allowed up to 32 characters including “.csv”. Use Cobra Audio Box Select ‘Yes’ if you plan to shoot your show using the Cobra Audio Box, otherwise select ‘No’. Audio Box Filename This corresponds to the filename of the MP3 soundtrack that you plan to load into the Cobra Audio Box. The name that you specify here will be added to the header in the script file and must match exactly to the filename of the soundtrack that you load into the Audio Box. For example, if you specify “audiobox.mp3” in the script export options dialog, then the filename of the soundtrack that you load into the Audio Box must be “audiobox.mp3”. If the Audio Box filename in your script and your soundtrack filename don’t match, your show will not fire. In COBRA firmware v3.X and 4.X, the Audio Box filename must be “audiobox.mp3” and is not editable. In COBRA firmware v5.0.X, the Audio Box filename can be custom, but must be 12 characters or less including the .mp3 file extension. In COBRA firmware v5.1.X and v6.X, the Audio Box filename can be custom, but must be 31 characters or less including the .mp3 file extension. Note: The Audio Box filename may contain lowercase letters a-z, uppercase letters A-Z, numbers 0-9, hyphens ‘-‘, underscores ‘_’, and spaces. No other characters are permitted. The filename of the music soundtrack that you place on your USB drive and insert into the COBRA Audio Box must be identical to the filename you enter here. SMPTE Timecode (COBRA v5.1 and higher) Select among three timecode choices: None, Timecode 1, and Timecode 2.  This choice merely fills into the header of the exported script.  The choice does not affect any other timecode related features, including the exported soundtrack. Timecode 1 – The 18R2 will continue to fire even if the timecode is lost or the quality is too poor. Timecode 2 – The 18R2 will stop firing if the timecode is lost or the quality is too poor. If the timecode stops, fast forwards, or is rewound, the 18R2 will keep in sync with the timing. Trigger Channel Choose the channel that the 18R2 remote needs to be on as a precondition for the user to initiate this script: 0-99, or the option “None”.  The option “None” indicates no specific channel is required as a precondition for initiating this script. Return Channel Choose the channel that the 18R2 remote returns to automatically upon completion of the script, 1-18 or “None”. Trigger Button Subject to the Trigger Channel precondition, the Trigger Button is the button on the 18R2 remote that triggers the script, 1-18, or the STEP button, or the AUTOFIRE button. If you choose the script type Separate Scripts By Tracks, then the Track field in Finale 3D that groups together sections of the show into separately triggered scripts on the 18R2 also specifies the Trigger Buttons for the separate scripts as being the Track numbers. Deadman Button / Trigger Confirmation Button Choose “None” or optionally a button 1-18 or “Deadman” as a confirmation button for triggering the script.  The choice cannot be the same as the Trigger Button. Disable Firing Button Choose “None” or optionally a button 1-18 to disable firing during a show. Alternate 1 Button Choose the button associated with “Alternate 1” script events (see “Alternates” in Table 2). Alternate 2 Button Choose the button associated with “Alternate 2” script events (see “Alternates” in Table 2). Exclude alternates from script body Choose whether alternates are double listed in the body of the script (see “Alternates” in Table 2). First event of Step By Events scripts fires when script starts Choose whether Step By Events scripts, when triggered, require pressing the STEP button for the first event or whether the first event fires immediately when the script is triggered.  This option is typically not checked unless if you choose the STEP button as the Trigger Button for the script, in which case it is a matter of personal preference.  The option only affects Step By Events type scripts. Sampling rate for continuously changing parameters Determines the number of script events generated per second for DMX effects that change smoothly over time, known as ramps. A ramp is a gradual change in a DMX channel’s value—such as a fade, color transition, or moving-head motion—rather than an instant jump. A setting of 10 Hz (recommended) means Finale 3D creates 10 script events per second to represent a ramp, producing smooth results without greatly increasing the script size. This setting applies to Cobra firmware v7.1 and earlier. Starting in v7.2 and later, each ramp is represented by a single script event. For example, at a 10 Hz sample rate, a 1-second ramp that required 10 lines of script in v7.1 and earlier now requires only 1 line. After the header, each row in the script has a number of fields separated by the vertical bar character. The names of these fields and their descriptions are shown in Table 4.   Table 4 – Specifications of script fields Column in Excel Field name Description A Event Time Ignition time of the event, in the format: 00:00:01.00s. B Channel Channel number (same as the Module Number and Rail Address), in the format: channel 10. (Blank for DMX rows.) C Cue Cue number (same as the Pin Address), in the format: cue 1. (Blank for DMX rows.) D Name Effect name, followed by the part number in curly braces (COBRA v6.0 and higher; non-DMX effects only), followed by double-slash and the name of the position or positions, followed by double-dash and the DMX channel label and channel offset in parentheses if event is a DMX event.   If the name contains a fixture ID / effect ID annotation in the format “[xxx/yyyy]” the fixture ID will be removed since it is redundant with the name of the fixture that is typically also in the name.  The value is a text string, at most 62 characters long. PYRO EXAMPLE: "Red Chrysanthemum {G2SH1000} // Pos-01/Pos-02/Pos-03" DMX EXAMPLE: "EZPAR [1096] White Flash (sm) // Pos-01/Pos-02/Pos-03 -- Dimmer (+0)" The DMX example’s effect originally had a fixture ID / effect ID annotation of “[005/1096]” but the fixture ID “005/” was removed from the exported name. E Disable Groups (COBRA v7.0 and higher) Text string identifying a group of events that can be disabled on the fly based on conditions during the show. F Pulse Time (COBRA v6.0 and higher) Duration for which cue is to be energized, in floating point format (0.01 second resolution); or blank for the default duration. Finale 3D writes the empty string value, unless the cue contains an event of type sfx, flame, light, or not_an_effect, in which case Finale 3D writes the duration of the event as shown in the script row. See Why is ‘Type’ so important? What depends on it?. G DMX Ramp-From Value (COBRA v7.2 and higher) Blank for no function, or an integer from 0-255 specifying the “from” value for the DMX channel to interpolate from over the DMX Duration (Column K); the DMX Channel Value (Column J) is the “to” value.  The channel value will remain with the “to” value indefinitely after the duration until set to another value by another event. H DMX Universe (COBRA v6.0 and higher) Integer from 1-100, identifying the DMX universe. (Blank for non-DMX rows.) I DMX Channel (COBRA v6.0 and higher) Integer from 1-512 identifying the DMX channel of the row. (Blank for non-DMX rows.)  NOTE: as of 4/2/2021 Cobra hardware is limited to 200 channels, 1-200. J DMX Channel Value (COBRA v6.0 and higher) Integer from 0-255 identifying the value for the DMX channel. (Blank for non-DMX rows.) K DMX Duration (COBRA v6.0 and higher) Duration of DMX command, or blank to leave the DMX channel value as is until a subsequent script row for the same channel changes the value.  The length of time can be between 0 seconds and 10 minutes at a resolution of 1/100th second.  The format is MM:SS.XX.  For example, 1 minute, 10.3 seconds is 01:10.30.  For COBRA v7.2 and higher, the DMX duration defines the period over which the DMX channel value interpolates from the DMX Ramp-From Value (Column G) to the DMX Channel Value (Column J) if the ramp-from value is not blank.  This field should be blank for non-DMX rows. An example semi-automatic script with two sections is shown below. The first track section contains two events with disable groups (wind, rain), and a third event with an explicit pulse duration. ##version 6 #Track 1 0,1,,0,audiobox 00:00:00.00s,channel 1,cue 1,White Chrysanthemum {G2SH1000},wind, 00:00:02.90s,channel 2,cue 1,White Chrysanthemum {G2SH1000},rain, 00:00:05.40s,channel 2,cue 4,Long Flame Projector Shot {GXX1101},,0.41 #Track 2 0,2,,0,audiobox 00:00:00.00s,channel 5,cue 1,Green Chrysanthemum {G2SH1001},, 00:00:01.00s,channel 6,cue 1,Green Chrysanthemum {G2SH1001},, 00:00:02.00s,channel 7,cue 1,Green Chrysanthemum {G2SH1001},, 00:00:03.00s,channel 8,cue 1,Green Chrysanthemum {G2SH1001},, end Figure 2 – Example Cobra script   Table 5 – Example files Download link Explanation test_cobra.fin Example show test_cobra_standard_script.csv Example exported standard script (fully-automatic) test_cobra_separate_scripts_by_tracks.csv Example exported semi-automatic script (separate scripts by tracks) test_cobra_step_script_by_tracks.csv Example exported step by tracks test_cobra_step_script_by_events.csv Example exported step by events magicfx_cobra_standard.fin Example DMX show using MagicFX flame projector magicfx_cobra_standard.csv Example exported DMX script using MagicFX flame projector  

Every effect or other kind of part in the effects table has a Type, chosen from a list of twelve predefined options. Other fields, like Category, Rack Type, and Subtype, allow the user to make up the categories or other possibilities for his own purposes, but not Type. Type is different, because the software functions look at the Type value to determine how to handle the part. For example, the function that adds all the necessary racks to the show needs to know what effects require mortars — shells do, cakes do not. By looking at the Type field, the function can know to add mortars for the shells, but not for the cakes. There are other things that depend on Type also. They are all described in the following table that lists the twelve pre-defined Type values and what they mean. You will notice that the types are entirely lowercase, with underscores instead of spaces, and they are in English. Those typographical conventions are a clue that the Type values are never translated to other languages. No matter what language you are using, the Type values will always be cake, candle, shell, and nine others.   Table 1 – Differences between the twelve pre-defined Types Type Notes Assigned firing system address or DMX channel; included in script Has adjustable duration Implies pulse duration Requires mortar rack Requires non-mortar rack Requires e-match; included in script report Has VDL-based icon Rotationally symmetric Safety distance is meaningful Included in sales orders cake YES YES (cake rack; unless sleeved in which case single-shot rack) YES YES YES YES candle YES YES (candle rack; unless sleeved, in which case mortar rack) YES YES YES YES YES shell YES YES YES YES YES YES YES ground YES YES (cake rack; unless sleeved in which case single-shot rack) YES YES YES YES YES other_effect Other pyro effects, like set pieces. YES YES YES but only if sleeved, in which case single-shot rack YES YES YES YES sfx Cryo, confetti, stadium shots, and adjustable duration flame. YES NO if the effect’s duration in the effect window is zero, or if the effect is a fixed duration predefined DMX program; YES otherwise. YES YES YES flame Fixed duration flame machine effects; change Type to sfx if you want to edit the Duration field in the script directly. YES NO if the effect’s duration in the effect window is zero, or if the effect is a fixed duration predefined DMX program; YES otherwise. YES YES YES light YES (except NO if effect is on drone position) NO if the effect’s duration in the effect window is zero, or if the effect is a fixed duration predefined DMX program; YES otherwise. YES YES rocket YES YES (candle rack) YES YES YES YES YES mine YES YES YES YES YES YES YES comet YES YES YES YES YES YES YES single_shot If a pyro effect goes into a single shot rack, then its Type must be single_shot, not comet, mine, etc. YES YES (single-shot rack) YES YES YES YES YES not_an_effect YES YES YES rack YES macro Causes the macro effect to expand into other effects when inserted into the show instead of being inserted into the show itself. The next table gives explanations of what the differences mean.   Table 2 – Explanation of the differences Dependency Description Assigned firing system address or DMX channel The “Addressing > Address show” function and other addressing functions assign firing system addresses (including module addresses for DMX-based effects) if this value is YES, and do not if this value is NO. Any effect that has a representation in the exported firing system scripts requires a firing system address, so if the value is NO, the item will not appear in the exported scripts. Items with the value NO may be useful for comments or triggers of non-firing system related actions. Has adjustable duration Generally the Duration field in script rows comes from the Per-show effects list by reference — the Part Number in the row matches the Part Number of an effect in the Per-show effects, and the Duration defined by that effect applies to script row. If you change the Duration of the effect in the Per-show effects, that will automatically change the duration of all rows in the script that refer to that effect. There are two exceptions: chain rows, and rows referring to effects whose Type implies the effect may have adjustable duration (sfx, flame, and light). In these cases, when the effect is inserted into the script, the effect’s Duration is copied by value into the script, and no reference or link is maintained to the original duration. You can edit the Duration of adjustable duration effects directly in the script rows, and different rows with the same effect can have different durations. Effects of type sfx, flame, or light have a fixed duration if their duration in the effects window is zero, or if they are standard effects representing fixed duration predefined DMX programs, which are common in moving head and multi-head flame fixtures and special effect fixtures like the Explo X2 Wave Flamer or the Showven Sparkular Waver Sparks Machine.   If the effect is a standard effect created from the menu item “DMX > Create or update standard effects for DMX fixture” then its part number identifies the standard effect ID, which identifies whether the effect is a fixed duration predefined DMX program. The downside of adjustable duration effects is that if you change the effect’s Duration in the Per-show effects, you might expect it to change in the show, but it doesn’t, because for these effects the Durations in the script are decoupled from their original definitions. The upside of adjustable duration effects is that for some applications you may want to be able to control duration on a row-by-row basis, and adjustable duration lets you do that. Implies pulse duration The pulse duration refers to the period of time the firing system pin is electrified for the effect. For most pyro effects, the pulse duration is just long enough to ignite the e-match, and doesn’t vary from effect to effect. But for flames and some other kinds of special effects, the pulse duration of the firing system is the duration of the effect. Depending on the firing system, the rows in the exported firing system script may contain a pulse duration value equal to the effect’s Duration only for effects that imply pulse duration. Exported scripts for the 100Hz Cobra systems, for example, have a blank pulse duration field for pyro and a pulse duration equal to the effect’s Duration only for effects that imply pulse duration. Requires mortar rack The rack layout functions of Finale 3D add racks for the types of effects that need them. If the Type field of the effect is shell, mine, or comet, then the effect requires a mortar rack. Other types of effects, like cake and single_shot, require different structures of racks (non-mortar racks). Some types of effects, like not_an_effect, do not require a rack at all. Requires non-mortar rack Different Types of effects require different rack structures. If the Type field of the effect is cake, candle, ground, or single_shot, then the effect requires a special structure of rack for that Type of effect. The rack structure is specified in the rack’s VDL field, and is mortar rack by default if the VDL field is blank. You can view or edit a rack’s structure in the “Create rack” or “Edit rack” dialog. Requires e-match The summary dialog presented after addressing the show displays the number of required e-matches. Items that do not require e-matches do not contribute to the e-match count. Has VDL-based icon VDL-based icons are simulations generated from the VDL field and other fields like Duration and Size, but only for the Types that make sense. Parts of Type rack have a special-purpose icon based on the Size. Parts of Type not_an_effect have a generic icon. Rotationally symmetric Items shot out of tubes, like shells, mines, and comets, are rotationally symmetric around their direction axis, the axis of the tube.  Rotating a shell within its tube doesn’t have much bearing on the appearance.  Effects like cakes and set pieces, however, are not rotationally symmetric around their direction axis, which is usually “up”.  Rotating a fan cake 90 degrees changes the fan from front-facing to side-facing. An effect’s rotational symmetry affects the rotation required of a rack to hold the effect at its proper orientation.  Non-rotationally symmetric items like cakes in a cake or ground rack will require the rack’s heading to match the effect’s pan.  Non-rotationally symmetric items like slice cakes in a single-shot rack will require the rack’s heading to be orthogonal to the effect’s pan so the physical width dimension of the slice cake aligns with the rows of the rack (cakes can be forced into single-shot racks using sleeving or Rack Type part numbers). Safety distance is meaningful Site layout diagrams that include safety circles based on effects’ safety distances will exclude effects for which the safety distance is not meaningful. Lights do not have meaningful safety distances but effects of type “sfx” do, because sfx effects may include variable duration flames. Included in sales orders The menu item, “File > Finale Inventory > Update sales order from used quantities” will ignore effects like flame effects and light effects because they do not represent physical inventory items.

It sounds like a simple question: How can I tell if an effect is a chain?  The reason it is not simple is that multiple pieces of information about the effect can be inconsistent, some indicative of a chain, others indicative of not a chain.  For example, the description could include the word “Chain”; the VDL could include the word “Chain”; either field could also include the word “Cake”; the “Devices” column could have multiple devices (looking like a chain) or a single device (looking like not a chain).  If you are puzzling about the behavior of an item that might be a chain, you can follow these rules to determine if it is a chain: Table 1 – How the software determines if an effect is a chain Chain Not a chain In Effects window Row defines a chain if the VDL contains the word “Chain”, or if the VDL is empty but the VDL that would be created automatically from the “Description” column would contain the word “Chain”. Otherwise In Script Row is part of a chain if it has a reference number in the “Chain” column Otherwise   The number of devices that a chain effect in the Effect window represents is the number in the “Devices” column — even if that number is inconsistent with the description or VDL of the effect.  This can be a source of confusion, because you might have an effect called “Chain of 5” with the number 10 in the “Devices” column.  Although it looks like a chain of 5 by the description (particularly if the “Devices” column happens to be hidden), the chain represents 10 devices.

In Finale 3D, chains are represented by one row in the script per device in the chain. It may not look like that, because the “Show chains as one row” setting in the Script window’s gear menu is on by default, but regardless of the display format, each device is a single row behind the scenes. Thus a chain of 10 devices is represented by 10 rows. The rows are bound together by virtue of having the same reference number in the “Chain” column, which is also what determines whether the row is part of a chain at all (see “How can I tell if an effect is a chain?”). If a show had two chains, each with 10 devices, then the show would have 20 rows total, and 10 of those rows would probably have “Chain” values of #1; the other 10 would have “Chain” values of #2. When you insert a chain or import a show with chains, the chains will be expanded out in the script to one row per device. Imported scripts can represent chains as multiple rows, just like in the script window of Finale 3D, if the script format has a “Chain” column with distinct reference numbers for the chains. The Finale Generic CSV format supports this column. Most script formats don’t have “Chain” column with this meaning, though, so most script formats resort to representing a chain in a single row in the script. As mentioned earlier, the “Quantity” column in the script format may represent number of chains or number of devices. If a single row in the imported script represents an entire chain, or even multiple chains, then the row will be expanded in the import process to multiple rows in the Finale 3D script, one row per device. Chain reference numbers will be added automatically to group the devices of a chain together. If you are importing shows with chains, please look at the “Chain” column to understand what is going on. Rows in the script that are part of a chain, i.e., that have a reference number in the “Chain” column, are treated specially. To begin with, you will notice that they appear different on the timeline. You may also notice, perhaps by trial and error, that their “Duration” column is editable, and contains a value that is usually different from the “Duration” value of the corresponding chain effect definition in the Effects window. This is unusual. The “Duration” column in the script is only editable if the row is part of a chain, or if the row’s effect has type other_effect or not_an_effect. Otherwise, the duration is a reference to the effect definition itself. The reason rows that are parts of chains cannot have a reference to the effect definition is that the duration of a chain is the duration from first to last launch, not the duration of an effect in the chain. The chain’s duration would almost certainly be wrong for the effect in the chain. Thus when you import a show with chains, or when you insert chains into the script, the “Duration” field for those rows will be filled in automatically with the specified or default duration of the effect itself. Similar to the “Duration” column, chain rows in the script have a special column called “Chain Device VDL,” which is usually hidden. This field specifies the VDL for the row’s device, which could be different from other devices in the same chain, and is definitely different from being the entire chain. For example, the chain “Red Peony + Blue Peony + Green Peony Chain of 3” has three shells, all different. The VDL for the chain is that full description (the same for all rows in the chain). The VDLs for the devices in the chain are “Red Peony” “Blue Peony” and “Green Peony” (different for each row). Figure 1 – The “Used” column depends on “Devices” and the user setting: “Display chain…”   In the effects window, the “Used” column that shows the number of chains used depends on the “File > User settings > Display chain ‘Used’ quantity as per-shell” setting.  If you have this setting checked, then the number displayed in the “Used” column for chains is just the number of devices in the script of that part number.  However, if you have the setting un-checked, then the number displayed in the “Used” column for chains is the number of devices, divided by the “Devices” count in the effect window, unless the Devices count is blank or zero, which is treated the same as the value “1”.   The chain quantity in the “Description” field and the “VDL” field does not affect the Used quantity; only the Devices field does. Since chains are expanded into their constituent devices when the chains are imported or inserted, it is difficult to edit chain simulations after importing or inserting them. The “Edit simulation” function in the effect window changes the original definition of the chain, but that only affects the expanded devices in the script to the extent they still reference those characteristics from the chain definition. The Duration, Chain Device VDL, and Prefire fields, as well as the number of devices, are all decoupled from the chain definition after insertion, so editing the definition won’t affect those characteristics of chains already inserted into the show.

Importing chains is complex because people follow different conventions for the meaning of chain quantity.  To some, quantity 10 of “Chain of 10” means a total of 10 devices; to others it means a total of 10 chains of 10 devices, for 100 devices total. Figure 1 – Does “Quantity = 5” mean 5 chains or 5 shells?   When importing a show, the dialog asks you if the chain quantity means number of chains or number of shells.  It’s really important that you answer that question correctly, or you could end up with 10 times as many chains as you want, or with boring chains of 1 shell each.  If your imported script format does not have a quantity column, then please select “Means number of chains”.  If it does have a quantity column, then select “Means number of chains” or “Means number of devices” depending on whether the quantities are the numbers of chains or the numbers of shells. The import dialog isn’t the only factor.  An effect description or VDL may specify the number of devices, as in “Red Peony Chain of 10” or may just indicate the effect is a chain and leave the number of devices off, as in “Red Peony Chain”, relying on the “Devices” or “Quantity” column to fill in the number. An imported show or effects list may or may not contain an optional “Devices” column or a “Quantity” column.  Depending on the presence of these columns, and the values in them, each row of the effects list or show will correspond to a certain number of devices inserted into the show (immediately for an imported show, or when clicking on an item from an imported effects list). Based on these variations and based on your choice in the import dialog, the following rules determine the number of inserted devices for a row of the imported effects list or show:   Table 1 – Factors affecting imported chains, and the number shells represented. Operation Quantity in VDL or Description column (X) Quantity in Devices or Quantity column (Y) Number of devices that will be inserted Importing effects Missing Missing 10 Importing effects 1 or more Missing X Importing effects Missing 1 or more Y Importing effects 1 or more 1 or more Y Importing show, number of devices option Missing Missing 1 Importing show, number of devices option 1 or more Missing 1 Importing show, number of devices option Missing 1 or more Y Importing show, number of devices option 1 or more 1 or more Y Importing show, number of chains option Missing Missing 10 Importing show, number of chains option 1 or more Missing X Importing show, number of chains option Missing 1 or more 10 * Y Importing show, number of chains option 1 or more 1 or more X * Y When importing a chain into a show from a single row or inserting chains into a show, the prefire of the chain applies both to the chain itself and to all the devices in the chain. In other words, the chain’s prefire and the prefire of its devices are one and the same. When importing a chain from multiple rows that are grouped together with the reference number in the “Chain” column, or when combining effects that already exist into the show into a chain, the first device’s prefire will be the prefire of the chain, and the other devices in the chain may have different prefires if they are different part numbers. When importing chains into a show, the effect definitions in the imported Per-show effects will have “Duration” equal to zero, and “Devices” equal to one, always. Neither of these fields is referenced by the chain rows of the script (see “Representation of chains in the script”). The same chain part number could be imported with different numbers of devices, which implies the duration and number of devices of the chain may not have a single unique definition. The values of these fields are cleared in order to guarantee consistent results. When importing chains into the Effects window, the duration of the chains is determined by: the “Duration” column in the imported row if present, else the duration specification in the “VDL” column if present, else the duration specification in the “Description” column if present, else a default duration calculated from the number of devices in the chain, that number of devices being the value in the “Devices” column if present, else the specification in the “VDL” column if present, else the specification in the “Description” column if present, else 10. The calculation of the default duration is, ChainDuration = ( NumberOfDevices - 1 ) * 0.05 The specification of the duration in the “VDL” or “Description” column is a quantity followed by the letter “s”, as in “8s Salute Chain Of 5”. The specification of the number of devices is either explicit, as in this “Chain Of 5” example, or implicit, based on the number of device descriptions are in the chain description, separated by plus signs (+), such as the chain of 3 devices described as, “Red Peony + Blue Peony + Green Peony Chain”. Figure 2 – The “Used” column depends on “Devices” and the user setting: “Display chain…”   In the effects window, the “Used” column that shows the number of chains used depends on the “File > User settings > Display chain ‘Used’ quantity as per-shell” setting.  If you have this setting checked, then the number displayed in the “Used” column for chains is just the number of devices in the script of that part number.  However, if you have the setting un-checked, then the number displayed in the “Used” column for chains is the number of devices, divided by the “Devices” count in the effect window, unless the Devices count is blank or zero, which is treated the same as the value “1”.   The chain quantity in the “Description” field and the “VDL” field does not affect the Used quantity; only the Devices field does.  Please note that the Devices field gets filled in from the Description or VDL field in the imported script, but thereafter the Devices column is independent.  If you manually change the Description or VDL fields after importing the show, that will not affect the Devices column and will thus not affect the displayed Used column. As you can conclude from the foregoing description, importing chains is complicated.  It is nearly impossible to edit chain simulations or specifications after importing them as part of a show, because when chains are inserted or imported, they are expanded to their constituent devices that are independent of the original chain definition with respect to multiple factors.  If you need to change chains after importing, the easiest solution is to delete them from the show and re-insert them manually.   

The chain duration for any chain is “first launch to last launch,” without exception. The prefire of the chain is the prefire of the first effect in the chain if it is a shell, and is an arbitrary offset into the effect otherwise. Type of item Prefire Duration Timeline duration Chain The value specified in the prefire column, if present, else in the VDL, as in “Chain of 5 Salute 0.0 PFT”, else the default lift time for a shell of this caliber if the first device is a shell, else zero; the lift time of the all effects being adjusted (if they are shells) to equal the specified prefire only if the prefire is non-zero First launch to last launch Expiration of the star or stars or emission of the last device — minus the prefire; or zero if that would be negative To calculate the delays in between the devices of a chain with more than one device based the duration of the chain, simply divide by the number of shots minus one. DeviceSeparation = ChainDuration / ( NumberOfDevices - 1 ) If a chain has a single device, its duration is zero, by definition, even if the value in its “Duration” column in the Effects window is something else.

To create and export a script for the Pyroneo (formerly SkyDirector) 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 Pyroneo firing system   The Pyroneo (formerly SkyDirector) script is a CSV-style text file that supports semi-automatic sequences, hazard classes, multi-hit pins, and pulse durations.   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text .csw ASCII | CRLF The script contains rows for the firing events, i.e., unique combinations of module, pin, and ignition-time. Multiple effects can be combined on a single cue. The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Sort order of rows Rows sorted ascending first by Sequenz (sequence), then by RelZeit (time). What rows represent Rows represent firing events, i.e., unique module-pin-ignition-time events. If multiple effects are triggered on the same cue, the effects are combined in name field, but the row is still just one row. Header If the script has music, it will begin with a header row of the form, #mTESTDIR\MUSIC, where TESTDIR\MUSIC is the path of the music file, without the file extension. Next is a comment row beginning with a semicolon, showing the column names in the same format as the CSV-style rows themselves. Special characters If a field contains the character | or “, then the field will be enclosed in “ on both ends, and any internal “ characters will be doubled up, following the Excel quoting convention. Minimum separation between cues None Semi-automatic firing In Finale 3D, the Track property in script rows indicates the section of the show to which the row belongs (please unhide the Track property in the script to use this feature). The rows in each section of a semi-automatic script have time values relative to the first event in the section, which is always time zero. In the Finale 3D script, the sections can be in any order and can even have interwoven events, but generally people place the sections one after another in the Finale 3D script, with some space in between to tell the apart. If you are scripting a fully automatic show, please ensure the Track values in the script are blank, because otherwise your show will be split up into zero-relative sections in the exported script. See semi-automatic-firing for further instructions. Track labels In Finale 3D, the Track field holds the track number and the track label together, as in “01 Opening” or “02 Middle Section”.  The track number is the first number contained in the string, e.g., the number 1 in “01 Opening” or “Opening 01”.  The track label is the string itself after skipping over any leading number in the string and trimming whitespace.  For example, the track label of “01 Opening” is “Opening”; the track label of “Opening 01” is the same “Opening 01” because the string doesn’t begin with the number. The best practice for representing track numbers and labels in the Track field in Finale 3D is to use a two digit number padded with a leading zero if necessary, followed by the track label.  The reason for the two digits and for putting the number first is to make it possible to sort the script window in Finale 3D by the Track column numerically. Multi-hit pins Supported in the script format and with manual addressing in Finale 3D, for non-pyro effects like flames and relays that can be triggered multiple times. Finale 3D handles multi-hit pins in the Pyroneo exporter the same as it handles single-hit pins — whatever pin address is in the script row in Finale 3D will be copied to the exported script row for Pyroneo, whether or not the pin address is unique. The standard pyro addressing functions in Finale 3D assign pins sequentially, so it may be easiest to address multi-hit pins in Finale 3D by editing the script table by hand and then locking the edited rows so the show can be re-addressed for pyro without affecting them. Slats Supported in Finale 3D using virtual slats. Virtual slats allow you to partition the channels of a module into separate slats for which you can assign addressing constraints to guarantee good pin assignments for your physical layout. For example, suppose you have one module with 20 pins that are distributed out to four launch positions on four physical “slats” or “rails” with five pins each. It would be important to have the addressing constraint that each slat is restricted to a single launch position, for otherwise you might have wires running from position to position. But the Pyroneo script format doesn’t have a notion of slats; each module simply has some number of pins, numbered incrementally, such as 1..20. To partition the pins into slats, create a custom module with a rail address template like #99-D-#5 to split the 20 pin modules into four 5-pin slats, A, B, C, D. Because these are virtual slats, even though their addresses appear in the format “2-B” and “3” for module 2, slat B, pin 3 (of slat B), the addresses are converted automatically in the exported script the contiguous pin range of the module. The virtual slat address “2-B” and “3” convert to module 2, pin 8 (pins 1-5 correspond to slat A, so the third pin in slat B is pin 8). After the header, each row in the script has a number of fields separated by the vertical bar character. The names of these fields and their descriptions are the following:   Table 3 – Specifications of script fields Field name Description Shownummer Show number from 0 to 15. Finale 3D writes 0. Sequenz Sequence number for semi-automatic sequences, or 0 for fully automatic shows. In Finale 3D, the value of the “Track” field of script rows fills into this field in the exported script. All events in the same semi-automatic sequence should have the same “Track” field value, which must be greater than 0 and not in the range 4080 to 4089. Flags Bit flags. Bit value 64 indicates the row is a sequence name; otherwise it is a cue. RelZeit Time in milliseconds from the beginning of the sequence or beginning of the show (depending on the Sequenz field), at which the cue is energized. The first cue in a sequence always has a value 0, by definition. Modulnummer Module number, beginning with 1. Einschaltdauer Duration for which cue is to be energized, in milliseconds, from 10ms to 65000ms. Finale 3D writes the value 250, unless the cue contains an event whose Type field is flame, other_effect, or not_an_effect, in which case Finale 3D writes the duration of the event as shown in the script row (or 250ms if no duration is present). See Why is ‘Type’ important?. Kanalnummer Pin number, beginning with 1. Gruppe Hazard class, a number 0 to 9. Finale writes the value from the “Hazard” field. The default value is 0. Position The position name, max length 8 characters. Name The effect name or sequence name; max length 32 characters. An example semi-autonomous script with two sections is shown below. Notice that each section begins with an event at time zero, since rows in sections are always relative to the first row in the section. Notice also that the last event in the script is a flame projector with an explicit pulse duration of the effect (410ms) rather than the 250ms default. #mtest_pyroneo ; Finale 3D Pyroneo export format v1.0 ;Shownummer|Sequenz|Flags|RelZeit|Modulnummer|Einschaltdauer|Kanalnummer|Gruppe|Position|Name 0|1|0|0|1|250|1|0|Pos-01|Green Chrysanthemum 0|1|0|1000|2|250|1|0|Pos-02|Green Chrysanthemum 0|1|0|2000|2|250|1|0|Pos-03|Green Chrysanthemum 0|1|0|3000|3|250|1|0|Pos-03|Green Chrysanthemum 0|1|0|4000|4|250|1|0|Pos-05|Green Chrysanthemum 0|2|0|0|5|250|1|0|Pos-06|Green Chrysanthemum 0|2|0|1000|6|250|1|0|Pos-07|Green Chrysanthemum 0|2|0|2000|7|250|1|0|Pos-08|Green Chrysanthemum 0|2|0|3000|8|250|1|0|Pos-09|Green Chrysanthemum 0|2|0|10728|4|410|2|0|Pos-05|Long Flame Projector Shot ;Shownummer|Sequenz|Flags|RelZeit|Modulnummer|Einschaltdauer|Kanalnummer|Gruppe|Position|Name;Shownummer|Sequenz|Flags|RelZeit|Modulnummer|Einschaltdauer|Kanalnummer|Gruppe|Position|Name

If you know the duration of a cake, you can determine the average time between the shots within the cake with a few simple calculations. But that’s only the average time. If the cake has longer delays between the rows or a mixture of row firing speeds, then the calculations require more steps. This section walks through the procedure. First, consider a cake like, 10 Shot 25s Red Peony Cake 2.5s PFT Usually, cake descriptions don’t include the prefire time explicitly (e.g., 2.5s PFT), but we’ve included it in this description because the prefire of the last shot factors into the calculation of the timing. If the description doesn’t specify the prefire explicitly, then the prefire is a default value based on caliber. Here’s how the prefire factors in: the duration of a cake is “first launch to last break” if the last effect in the cake is a shell, as it is in this example. So to calculate the average time between the shots of the cake, the formula is, ShotSeparation = ( CakeDuration – LastShotLiftTimeIfShell ) / ( NumberOfShots – 1 ) Which in this example is, ShotSeparation = ( 25 - 2.5 ) / ( 10 - 1 ) = 22.5 / 9 = 2.5 seconds between shots In conclusion, the cake in this example has 10 shots, separated by 2.5 seconds. A second example illustrates a cake that has non-uniform timing: 20 Shot 15.0s (a) Red Comet + (b) Aerial Popcorn Crackle Cake, 4 Rows, Rows 1,2,3 (aaaaa/STR/2.0), Row 4 (0.5/bbbbb/FNT) Before calculating the shot timing, let’s review the description to identify what the specifications are, and what remains to be calculated. The cake has 20 shots, divided equally in four rows of five shots each. The first three rows are identical, firing a straight up sequence (“STR”) of effect “a”, the red comet, with a 2.0 second duration from the first to last shot within the row. The last row has a 0.5 second delay before the row, which is an all-at-once fan (“FNT”) of the “b” effect, the popcorn crackle shell. Assume for the sake of this example that the default lift time of the popcorn crackle shell is 2.5s. The first step in calculating the shot timing is to calculate the time from first to last shot: TimeFirstToLastShot = CakeDuration - LastShotLiftTimeIfShell = 15 - 2.5 = 12.5 All of the interior delays thus have to add up to 12.5. What are the interior delays? The delay timings within each row are regular, but the delays between rows can vary, and the rows themselves can have different durations, depending on the specifications. Any unknown delays are assumed to be identical, treating unknown delays between rows and unknown delays between tubes within rows as all the same. In this example, the delays are, FirstRowDuration + DelayBeforeSecondRow + SecondRowDuration + DelayBeforeThirdRow + ThirdRowDuration + DelayBeforeFourthRow + FourthRowDuration Or, 2 + DelayBeforeSecondRow + 2 + DelayBeforeThirdRow + 2 + .5 + 0 = 6.5 + 2 * DelayBeforeSecondAndThirdRow (the delays are the same) Knowing that the total must equal 12.5, we can calculate, 12.5 = 6.5 + 2 * DelayBeforeSecondAndThirdRow 6 = 2 * DelayBeforeSecondAndThirdRow 3 = DelayBeforeSecondAndThirdRow At this point, everything is known. The explicit 0.5 second delay before the last row adjusts the timing of the last row of the cake for dramatic effect. The popcorn crackle effect has an extra delay after the break before the crackling fully blossoms, so it might be a little surprising that 0.5s would be the proper delay between the firing of the last comet and the firing of the popcorn crackle shells, but if you see the simulation, you’ll agree. After all, it is what the cake looks like that matters!

In the Effects window, a chain is a single row, but in the script a chain is multiple rows, one per device. Thus when you insert a chain from the Effects window, a single row is being expanded out to multiple rows. This expansion only happens for chains, which you can recognize by the word “Chain” in the VDL column (See “How can I tell if an effect is a chain?”). The number of expanded rows is equal to the “Devices” column of the chain in the effect window, regardless of what the description or VDL of the effect might seem to indicate. If the “Devices” column has the value 1, the inserted chain will have only one device even if it is called, for instance, a “Chain of 5”. All the rows in the script reference the show’s local database of effects, called the Per-show effects, which are saved along with the show. When you insert a chain or any other effect into the show from a collection of effects, the effect definition (one row) is copied from the collection into the Per-show effects, overwriting the previous value or adding a new row if not already in the Per-show effects, by matching part number. The rows in the script representing the devices of the chain all reference the same effect definition in the Per-show effects for some of their attributes, such as “Description.” Other attributes, like “Duration” and “Devices” are calculated and automatically filled into to the script rows when the rows are created, because obviously the duration or device count of a chain would not be right for individual devices in the chain. (See “Representation of chains in the script.”) To accommodate effects lists that are missing important fields of information like “Part Type”, Finale 3D automatically derives any missing fields from the fields that are not missing when inserting the effect.  For example, the “Part Type” can be derived from the description of the effect or its VDL. It is actually this modified effect definition, with missing fields filled in, that is inserted or updated into the Per-show effects. Thus even if the effects list from which you insert an effect is missing columns, the effects will still show up in the show if you insert them. This automatic filling in applies to chains and to other effects that are not chains.