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, #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.