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, #mTESTDIRMUSIC, where TESTDIRMUSIC 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.

  Video 1 – How to Share Modules Across Multiple Positions   A common preference for addressing shows is that modules cannot be shared across launch positions.  The reasoning is simple: stretching long e-matches between positions is usually a bad idea.   Sometimes, however, groups of positions are close together or arranged in ways that make it a good idea to share modules within the groups, while still preventing sharing between the groups.  Launch positions mounted on a tower or truss may be only a few feet apart, for example. The shoot site in Figure 1 is another example, an outdoor layout with three groups of positions that are intended to share modules.   Figure 1 – Sharing example: the positions in each circle are intended to share modules.   The Section field of the position properties is the simplest way to control sharing on a small scale.  The addressing functions of Finale 3D have a required constraint that modules cannot be shared across different sections, so you can control sharing by setting the Section field of the positions.  By default, the Section field is blank. The addressing functions also have other optional constraints.   By default, one of the optional constraints is that modules cannot be shared across different positions, because that is the usual preference.  If you remove this optional constraint then the only constraint controlling the sharing of modules is the Section field.  By setting the Section field to unique values for each sharing group, you can control exactly what positions can share modules.   Figure 2 – Select the five front positions, right-click, and do "Edit properties" to set their Section.   You can set the Section field for positions by right clicking them and doing the function, "Edit properties" from the context menu.  If you select multiple positions and then right click on them with all of them selected, you can set the Section field of multiple positions at the same time, as shown in Figure 2.  Knowing that the addressing functions will not share modules across positions with different Sections, you will want to assign a unique Section value to the positions in each of the groups of Figure 1, and also a unique Section value to each independent position, which entails six Section values in all.  The Section values can be words or numbers or anything.  In this example, the letters a - f will suffice, as shown in Figure 3.   Figure 3 – It may be faster to set the Section values by editing directly in the Positions window.   Figure 3 also hints that it may be faster to set the Section values by editing the text in the Positions window.  Use the "Edit Properties" dialog or the Positions window, whichever you find more convenient.  Having set the Section values, if you then display the Racks window from the Window menu, you'll see the site layout automatically includes blue lines around the sections, which you can look at to verify the section arrangement is right.   Figure 4 – The Racks window draws section boxes around the positions.  Look how closely this window resembles the desired grouping in Figure 1.   When addressing a show using the “Addressing > Address show” function, you are given the opportunity to specify the module constraints in paragraph 3 of the dialog.  The module constraints control whether modules can be shared across different positions, or different angles, sizes, or any other properties.  By default, the optional module constraints include just "Position", allowing modules to be used across any effects but only within the same position.  To use sections for controlling sharing instead, please remove "Position" from paragraph 3 of the addressing dialog.  The section constraint is always present, as shown in Figure 5.   Figure 5 – The addressing functions always prevent sharing modules across sections.  Remove the optional constraints so sections are the only module constraint.    If your firing system is the type that has modules with slats, you may want to restrict slats from being shared across positions by adding "Position" to the slat row in Figure 5 (below the red markings).   That set of constraints distributes the module's pins to multiple positions within the same section but only as they are grouped in the slats.  The wires stretching between the positions are not the e-matches but are rather the cables connecting the slats to the module, or perhaps no wires at all if that connection is wireless.  Distributing pins between positions as they are grouped in multiple distribution boxes or rails of terminals can be useful even for firing systems that do not have slats explicitly represented in the firing system addresses.  You can apply this distribution scheme for those systems also, using "virtual slats" as described in Virtual slats and Slats, virtual slats, and splitter boxes. Sharing modules between some positions and not others is an example of a broader issue that sometimes different parts of a show need to be addressed differently.  The Pro version of Finale 3D has a feature called "Blueprints" that allows you to define different addressing rule sets for different parts of the show.  You can use blueprints as an alternative to sections or along with sections.  The merits of using blueprints depend on whether sharing modules is your only need, or whether module sharing is just one of many addressing considerations that can all be dealt with together using blueprints.   Addressing the show using blueprints (Pro only) An addressing blueprint is basically a saved copy of the choices in the “Addressing > Address show” dialog. You can create and name an addressing blueprint from the “Addressing > Create addressing blueprint” function. If you want to address some of the positions in the show with module sharing allowed, and others not, then you’ll need two blueprints. You could, for instance, create a blueprint called “Sharing” with the "Position" constraint removed as shown in Figure 5, and a second blueprint called “No sharing” with the "Position" constraint intact. Having created the two blueprints, you can divide the show’s positions into two groups, and assign the corresponding blueprints to the positions. Select all the positions for which module sharing should be allowed, then right click on that group of selected positions and choose “Edit properties” from the context menu.  Assign them the “Sharing” blueprint from the blueprint selector on the "Edit properties" dialog.  Then select all the other positions, edit properties, and assign them the “No sharing” blueprint.  All that is left to do is to address the show, but instead of using the “Addressing > Address show” function, use “Addressing > Address show using blueprints assigned to positions”.  This function will address the show sharing modules only among the positions within the "Sharing" group.    

Generally speaking, the duration of a cake or candle is “first launch to last break” if the last effect in the cake or candle is a shell. All other effect types -- comets, mines, etc. -- are considered to have a break time of zero, so for non-shells this calculation is equivalent to “first to last launch”. Most of the exceptions to this rule are obvious once you think about them. For example, a single-shot shell candle has the same duration as the shell itself: “break to expiration of stars”. Similarly, an all-at-once fan cake of shells or comets has the same duration as the shells or comets themselves, since they are all shot at once. So for most people, a perfectly useful definition of the duration of cakes and candles is “first launch to last break, except when it’s not, in which case it is obvious.” For people who need to understand the details, here they are: Type of cake or candle Prefire Duration Timeline duration to right of blip Single-shot cake or candle The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Peony Candle 0.0 PFT”, else the default lift time for a shell of this caliber; the lift time of the shell being adjusted to equal the specified prefire only if it is >= 0.5 (see Prefire) Expiration of the stars minus the prefire if the prefire >= 0.5; else the expiration of the stars minus the sum of the prefire and the default lift time for a shell of this caliber Expiration of the stars minus the blip Multi-shot, not-all-at-once cake or candle with first shot being a shell and last shot being a different effect from first shot The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Peony Candle 0.0 PFT”, else the default lift time for a shell of this caliber; the lift time of the first shell being adjusted to equal the specified prefire only if it is >= 0.5 (see Prefire) Effect time of the last shot (its break time if it is a shell or launch time otherwise) minus the launch time of the first shell; the lift time of the last effect being unaffected by any prefire specification in the VDL or prefire column; the launch times being delayed by the prefire if prefire < 0.5 Expiration of the stars of the last shot minus the blip Multi-shot, not-all-at-once cake or candle with first shot being a shell and last shot being the same effect as the first shot The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Peony Candle 0.0 PFT”, else the default lift time for a shell of this caliber; the lift time of the first shell being adjusted to equal the specified prefire only if it is >= 0.5 (see Prefire) Effect time of the last shot (its break time if it is a shell or launch time otherwise) minus the launch time of the first shell; the lift time of the last effect being determined by the prefire specification in the VDL or prefire column if >= 0.5; the launch times being delayed by the prefire if prefire < 0.5 Expiration of the stars of the last shot minus the blip Multi-shot, all-at-once cake or candle with first shot being a shell and last shot being a different effect from first shot The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Peony Candle 0.0 PFT”, else the default lift time for a shell of this caliber; the lift time of the first shell being adjusted to equal the specified prefire only if it is >= 0.5 (see Prefire) Zero Expiration of the stars of the last shot minus the blip Multi-shot, all-at-once cake or candle with first shot being a shell and last shot being the same effect as the first shot The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Peony Candle 0.0 PFT”, else the default lift time for a shell of this caliber; the lift time of the first shell being adjusted to equal the specified prefire only if it is >= 0.5 (see Prefire) Zero Expiration of the stars of the last shot minus the blip Single-shot cake or candle with non-shell The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Comet Candle 0.0 PFT”, else zero; a prefire < 0.5 representing a delay before the effect launches or begins emission in the case of a fountain Expiration of the star or stars in the case of a comet or mine, or expiration of the continuous emission in the case of a fountain, minus the launch time; the launch time being delayed by the prefire if prefire < 0.5; the timeline blip aligning to the prefire and not the launch if prefire >= 0.5 Expiration of the star or stars in the case of a comet or mine, or expiration of the continuous emission in the case of a fountain -- minus the blip; or zero if that would be negative Multi-shot, not-all-at-once cake or candle with first shot not being a shell The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Comet Candle 0.0 PFT”, else zero; a prefire < 0.5 representing a delay before the effect launches or begins emission in the case of a fountain Effect time of the last shot (its break time if it is a shell or launch time if it is a mine or comet or emission begin time if it is a fountain) minus the launch time of the first effect; the launch times being delayed by the prefire if prefire < 0.5; the timeline blip aligning to the prefire and not the launch if prefire >= 0.5 Expiration of the star or stars in the case of a comet or mine, or expiration of the continuous emission in the case of a fountain, of the last shot -- minus the blip; or zero if that would be negative Multi-shot, all-at-once cake or candle with first shot not being a shell The value specified in the prefire column, if present, else in the VDL, as in “Single-Shot Comet Candle 0.0 PFT”, else zero; a prefire < 0.5 representing a delay before the effect launches or begins emission in the case of a fountain Zero Expiration of the star or stars in the case of a comet or mine, or expiration of the continuous emission in the case of a fountain, of the last shot -- minus the blip; or zero if that would be negative To calculate the delays in between the shots of a basic sequential shooting cake based the duration of the cake, you must subtract the lift time the last effect in the cake from the cake’s duration if the last effect is a shell, and then divide by the number of shots minus one. ShotSeparation = ( CakeDuration - LastShotLiftTimeIfShell ) / ( NumberOfShots - 1 ) For cakes and candles with first shot being a shell, the shell’s lift time will be adjusted to equal the prefire if explicitly specified as >= 0.5 in the VDL or in the prefire column. Moreover, if the last shot in the cake (or any other shot in the cake) has the same effect as the first, that shot’s lift time will also be so adjusted, since it is the same effect.