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

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

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

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

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

Sketchup models on the 3D Warehouse site (https://3dwarehouse.sketchup.com/ ) often have satellite imagery terrain as part of the models.  You may or may not want that part of the model when you import the model into Finale 3D (instructions: Importing models).  On the one hand, you may want to import the model without its terrain so you can use the editable terrain of Finale 3D, with reflective water and optional imported background image or satellite imagery.  On the other hand, if the model you are importing has exactly the terrain you want already, then why not import it as is? By default, Finale 3D will automatically eliminate terrain in models that it recognizes are based on satellite imagery, since that is usually what people want.  If that's not what you want, you can edit the model in Sketchup to prevent Finale 3D from recognizing its terrain.  This section shows you how.   Figure 1 – Example Sketchup file with satellite imagery terrain.     Figure 1 shows an example Sketchup file with satellite imagery terrain.   Sketchup has "layers" in its model format.  The layers are identified by tags, as shown in Figure 2.     Figure 2 – The "Tags" of the layers representing satellite imagery terrain.   When Finale 3D imports a model, it examines the tags of the objects, looking for tags that contain the words, "google" and "earth" "location" and "terrain" "location" and "snapshot" If any layer has these words in its tag, then Finale 3D categorizes that layer as satellite imagery terrain, and removes the geometry when importing the model.  Thus if you want to prevent Finale 3D from excluding the terrain, you can simply change the names of the tags, as shown in Figure 3.   Figure 3 – Changing the names of the tags to make Finale 3D not recognize parts of the model as satellite imagery terrain.   Once you change the names of the tags, Finale 3D will no longer recognize the satellite imagery based terrain, and will import it along with the rest of the model.

Most of the constraint terms in the addressing dialogs for a module, slat, pin or rack are attributes of effects.  The standard meaning of a constraint of the form "Module restricted to single X" is that every effect fired from a specific module must have the same value for the attribute X, whatever X is -- Size, Part Number, Position, etc.  Loosely speaking, this standard meaning applies to all the constraint terms, but there are are few constraint terms that are not attributes of the effects or that work slightly differently.  These are the "Special" constraint terms.  They have meanings that are consistent with the standard meaning but require a customized implementation to do what people expect.  These special terms are listed in Table 1.   Table 1 – “Special” constraint terms in the addressing dialogs Constraint Meaning Angle Loosely speaking, this constraint requires that the effects have the same orientation. The orientation of an effect is defined by Euler angles Pan, Tilt, and Spin. All three Euler angles must be the same for the Angle constraint to be satisfied. Angle-Or-Not Loosely speaking, this constraint requires that effects are all straight up, or all angled, though the specific angles can vary. Ignoring Pan, an effect is considered to be "at an angle" if its Tilt or Spin Euler angle is non-zero. The constraint is satisfied for collections of effects that are either all at an angle or all not at an angle (independent of what the angle is). Angle-Plus-Minus Loosely speaking, this constraint requires that angles are leaning in one direction or the other or are straight up, though the specific angles can vary. The first Euler angle (Pan, Tilt or Spin) that has a non-zero value for an effect determines its "angle plus/minus/zero," based on the sign of the angle. If all the Euler angles are zero, then the "angle plus/minus/zero" is zero. The "Angle-Plus-Minus" constraint is satisfied for a collection of effects if all of them have the same "angle plus/minus/zero." Chain This constraint requires that all effects are in the same chain, or all effects are not in a chain. Chain-Or-Not This constraint requires that all effects are in chains (not necessarily the same chain), or all effects are not in a chain. Custom Script Field, Custom Part Field, Custom Numeric Field, Custom Position Field These constraints refer to properties displayed in the Script window for which blank values can be interpreted as wildcards (not including Rack Custom Field and Rack Custom Part Field, which are not displayed in the Script window).  In the addressing dialog, if you select, "Treat blank values for custom fields as wildcards" then blank values for any of these properties will not constrain possible assignments.  For example, if three events have Custom Script Fields of "A", blank, and "B", then a Custom Script Field constraint will prevent the "A" and "B" events from being assigned to the same module or slat or pin, but the event with a blank Custom Script Field could be assigned to the same module or slat or pin as either of the others. The Custom Part Field refers to a property of the effect definition in the Effects window.  The Custom Position Field refers to a property of the position in the Positions window.  The Custom Script Field and Custom Numeric Field both refer to properties of the event in the Script window. Event (If Single-Shot) This constraint requires that either none of the effects are single-shots, or there is exactly one effect.  If applied as a pin constraint, this condition is equivalent to limiting the max. e-matches per pin to 1, but only for single-shots, enabling you to have a different max. e-matches per pin limit for non-single-shots than for single-shots.  The re-arrange effects option for single-shot racks requires a single e-match per effect in the rack, which can be accomplished with this constraint specifically for single-shots or with the max. e-matches per pin constraint for all effects. Flight Count A "flight count" is the number of devices at the same event time and same position. A chain of five, by itself, has a flight count of 5 for all five devices in the chain. Two chains of five shot together have a flight count of 10 for all ten devices. Five shells unchained but shot together also have a flight count of 5. The Flight constraint requires that effects have the same flight count. Flight-Or-Not This constraint requires that all effects have a flight count > 1, or all effects have a flight count = 1, though other than that the effects do not need to have the same flight count. Group This constraint relates to the Group attribute but also takes into consideration the Chain attribute and treats blank values unusually. The constraint is satisfied if all events are in the same group (and are in fact in a group!), or if all events are in the same chain (and are in fact in a chain!). The Group constraint is useful for manually specifying what effects are to be e-matched together. Adding the Group constraint to pins will prevent events from being e-matched together unless you specifically give them a group identifier, like "TOGETHER" for example. You don't need to come up with unique identifiers for different groups of events because events can never be combined onto the same pin if they are at different times. Module (If Rack < 25 Tubes) This constraint on racks limits racks with fewer than 25 tubes to a single module, preventing racks that have just a few more tubes than the module from using a second module (leaving the tubes empty instead).  Imagine addressing a position for Cobra modules that have 18 pins. The position contains racks with 20 tubes (holders) and racks with 36 tubes. You would want the 36 tube racks to use two modules, while limiting the 20 tube racks to a single module, leaving two of its tubes unused. This constraint accomplishes both goals simultaneously. Module (If Single-Shot Rack) This constraint on racks limits single-shot racks to a single module. Other kinds of racks are unaffected by this constraint. One Single-Shot Rack This constraint restricts a module, slat, or pin to: zero or more non-single-shot racks in combination with zero or one single-shot rack, i.e., it prevents the module, slat, or pin from being shared across multiple single-shot racks, without preventing anything else. In combination with sorting single-shots first, this constraint is useful to allow the "extra" pins of modules that don't match pre-wired pins of a rack to be used for other types of effects, like cakes.  For example, if a module that has 32 pins is used for a pre-wired pin single-shot rack that has 30 holders bound to pins 1-30, the extra pins 31 and 32 could still be used for cakes. Pair This constraint requires that all effects have a flight count of 2. Pair-Or-Not This constraint requires that all effects have a flight count = 2, or all effects have a flight count != 2. Rack This constraint restricts a module, slat, or pin to serving a single rack.  Applied to pins, it prevents chains (which consist of effects on the same pin and e-match) and flights (which consist of effects on the same pin), from splitting across racks as described in Cross-loading chains with angled shells or using fan-racks. The constraint can also be used to restrict a module or slat to a single rack, but that is typically useful only for single-shot racks.  To apply this restriction for modules or slats to single-shot racks but not mortar racks and other kinds of racks, use "Rack (If Single-Shot)" or "One Single-Shot Rack" instead. Rack Cluster Rack clusters are collections of racks in a position that are snapped together in the rack layout view. It is natural to constrain modules or slats or pins to rack clusters to avoid unwieldy wiring.  A single rack by itself is also considered a rack cluster (of one rack) for the purpose of this constraint. Applied to modules or slats, this constraint prevents wires between physical clusters of racks.  Applied to pins, this constraint prevents chains (which consist of effects on the same pin and e-match) and flights (which consist of effects on the same pin), from splitting across multiple physical clusters of racks, as described in Cross-loading chains with angled shells or using fan-racks. If you want to restrict modules (or slats or pins) to groups of racks by your designation that aren't necessarily snapped together, you can make "virtual rack clusters" by setting the Rack Custom Field to a virtual rack identifier that is the same for racks in the same group, and adding the constraint "Module restricted to single RACK CUSTOM FIELD". Rack (If Single-Shot) This constraint restricts a module, slat, or pin to: a) a single single-shot rack or b) any number of non-single-shot racks.  In other words, a module restricted with this constraint could NOT serve effects in a single-shot rack and also in a non-single-shot rack. This constraint is useful for managing the allocation of modules across single-shot racks without affecting other types of effects.  The similar constraint "One Single-Shot Rack" also prevents a module, slat, or pin from sharing across multiple single-shot racks, but allows sharing between a single-shot rack and non-single shot racks. Rack Part Number, Rack Category, Rack Custom Part Field, Rack Custom Field These constraints refer to properties of the rack used for the effect.  The constraint "Module restricted to single RACK CUSTOM FIELD" means that every event fired from a specific module must use a rack with the same Custom Rack Field.  The Custom Rack Field is a field in the Racks window that can be edited for every rack instance in the show.  The constraint "Module restricted to single RACK CUSTOM PART FIELD" means that every event fired from a specific module must use a rack with the same Custom Part Field.  The Custom Part Field for the rack is part of the rack's definition, which is editable in the Effects window and which applies to all instances of the rack definition used in the show. Effects also have a Custom Part Field in their definition in the Effects window, so there is a possibility of confusion.  The constraint names are precise: the constraint Custom Part Field refers to the effect's Custom Part Field; the Rack Custom Part Field constraint refers to the rack's Custom Part Field -- both in the Effects window.  The constraint Custom Script Field refers to the effect's Custom Script Field in the Script window; the Rack Custom Field refers to the rack's Custom Rack Field in the Racks window. Rack Type (Of Rack) This constraint refers to the Rack Type property of the racks themselves, not of event rows in the script window. Section The module constraint row in the addressing dialogs includes the term "Section" as a required option, meaning that modules are never shared across different sections. It follows that slats and pins are also never shared across different sections, since it would be impossible to share a slat or pin without also sharing its associated module. There are a few other terms that modules implicitly cannot be shared across. The full list is: Universe, Firing System Type, Section, Addressing Blueprint, Start Module, and Module Type.  See Sorting positions across multiple blueprints or sections for more information. Slat (If Rack < 25 Tubes) This constraint on racks limits racks with fewer than 25 tubes to a single slat, preventing racks that have just a few more tubes than the slat from using a second slat (leaving the tubes empty instead).  Imagine addressing a position for fireTEK slats that have 16 pins. The position contains racks with 20 tubes (holders) and racks with 32 tubes. You would want the 32 tube racks to use two slats, while limiting the 20 tube racks to a single slat, leaving four of its tubes unused. This constraint accomplishes both goals simultaneously. Slat (If Single-Shot Rack) This constraint on racks limits single-shot racks to a single slat. Other kinds of racks are unaffected by this constraint. Tube Index -- Chain The tube index constraint forces chains to load across racks, as described in Cross-loading chains with straight-up shells.   Applied as an addressing constraint to pins, this constraint forces all the chain shells associated with the pin to occupy tubes at the same tube index, which means the chain shells will need to be spread out across multiple racks and will need to be at the same location within the racks: cross-loading! The constraint "Tube Index -- Chain" includes the phrase "-- Chain" to indicate that the constraint only applies to chains.  It does not apply to flights of independent shells ignited by the same pin.  This distinction is a convenience that allows you to add the constraint for addressing in general without it affecting pairs of shells or flights. The "Tube Index -- Chain" constraint also implicitly adds a "Chain Reference" constraint to the pin, which restricts the pin to a single chain (or non-chained shells), preventing multiple chains from being e-matched to the same pin.   If multiple chains were e-matched to the same pin, then the "Tube Index -- Chain" constraint would force all their shells to be at the same tube index, which would make for a very long row of racks. Lastly, the "Tube Index -- Chain" constraint only applies to pins.  Adding the constraint to the modules or slats does nothing because it doesn't make any sense. Tubes This constraint refers the the Tubes property of the effects, not of the racks.  For effects, the Tubes field can mean whatever the user wants it to mean, similar to the Custom Numeric Field.    

You can use background images to make a convincing but fake 3D scene by arranging the launch positions to look like the fireworks are coming from the buildings or other structures in the image.  The technique is called trompe l'oeil, and it is often the easiest way to create a simulation video with minimal effort.  Full instructions are here: Background images. Static videos taken from a single point of view, though, look dead in comparison to videos taken from multiple points of view or from a flying drone.  It actually doesn't take much camera motion to make the video feel alive.  It just takes some.  The difference is striking if you compare a video with no camera motion to a video with even the smallest amount of camera motion.  Once you see the difference, you'll never make a fully static video again. Unless you need to make a trompe l'oeil video!  In that case you may be wondering: is it even possible to add camera motion to a trompe l'oeil video?  The answer is yes, within parameters.  This section explains the technique, step by step.  Spending a half hour adding camera motion can be the difference between a video that looks dead or alive.   "Yes, within parameters" Trompe l'oeil videos rely on arranging the positions to align with the background image to make it look like the fireworks are coming from structures in the image.  From a single point of view, it is possible to arrange the positions the proper distances from the camera, to create the correct foreshortening, and to align the positions with perfect registration on the structures in the image.   If you get the positions to line up perfectly, it is almost impossible to tell the 3D the scene is faked.  But that is for a single point of view.  Camera motion changes the point of view, which causes the positions to fall out of alignment with the background image. Not all camera motion is the same, though.   Moving the camera forward or back is bad news.  That breaks the illusion immediately because it affects the view of the positions a great deal but only slightly affects the background image, making the positions fall out of registration with the background image immediately.  Moving the camera up into the sky also breaks the illusion, but there is one camera motion that affects the view of the positions and the background image in approximately the same degree: rotating the camera left/right.   Figure 1 – Beginning frame shows left end of the bridge in the background image.   Figure 1 and Figure 2 show the beginning and ending frame of a trompe l'oeil video of a fireworks show on a bridge.  The bridge is in the background image itself.  The fireworks spring from positions laid out to look like they are on the bridge.  Notice that in both of these images, the fireworks align pretty well with the bridge.   The camera angle in the second image has been rotating more than 90 degrees!   Figure 2 – Ending frame shows right end of the bridge in the background image.   In a nutshell, the technique for adding camera motion to trompe l'oeil videos is 1) setup your background image, 2) layout your positions to be at the proper distances and to align with the image, 3) create one camera key frame at the start of the show and a second camera key frame at the end of the show by orbiting the camera around by 90 degrees or so, or whatever looks good.  The end result is a slow, continuous glide of the camera over the entire show.  You aren't looking to attract attention with the camera movement.  You just want the video to look alive.  A link to the show file used in this example and a movie are at the end of this section.  Take a look at the file or the movie to see the end result!   Figure 3 – Original image used for the video.   Figure 3 shows the modest beginnings of this example show.  This is the picture that is imported as a background image.  Figure 4 shows the complete set of sky image adjustments that transforms the image of Figure 3 into the nighttime image that you see in the video.  The remaining paragraphs in this section walk through the steps of the technique, one by one, so you can see the significance of each sky image adjustment.   Figure 4 – Stretching the image horizontally -- even by a 100% or more -- doesn't look bad (amazingly).     Nine step technique The first step of the technique to add camera motion to trompe l'oeil videos is to import the background image and take a look.  You might see something like Figure 5, which clearly needs some adjustment.  Before adjusting the background image parameters or aligning positions, please make sure to turn on "Standard aspect ratio in edit mode (letterbox)" in the "File > Render settings..." dialog.  That will guarantee that what you are looking at when making adjustments is the same as what will appear in the video.  Without this setting, what you are looking at when editing would depend on the dimensions of the window, which usually aren't the same as the video dimensions.   Figure 5 – Preparation step #1: Import the background picture at default FOV (e.g., 120 degrees).  See how it looks.   The camera field of view parameter controls the fishbowl aspect of the image projection.  If the image hasn't been cropped, then matching the field of view of the camera that took the picture will result in the proper projection.   That may not help you, though, if you don't know the field of view your camera.  Most cell phone cameras have field of views of about 60 or 70 degrees.  You don't need to get it exactly right.  Just try a few numbers until it looks good.   Figure 6 – Preparation step #2: Adjust FOV to make it look right (in this case 70 degrees since the original image had been cropped).   Figure 6 shows the image after fixing the field of view.  At this point, you are all set for making a video with a single point of view.   To add left/right camera rotation, though, you'll need a wider panorama.  In fact, to rotate the camera 90 degrees and still to have room for blending the edges to black you'll need a significantly wider panorama!  Since the original image only captures the view ahead of the camera (not to the sides), it is hard to imagine where a wider panorama would come from. In French, "trompe l'oeil " means "trick the eye".  While it may seem brazen, you can trick the eye by simply stretching the image horizontally to enlarge the panorama.  Doing so will of course stretch everything in the image horizontally also, widening the buildings and bridges or anything else.  Surprisingly, though, stretching things horizontally, even by a large amount like 100% or 200%, actually isn't very noticeable unless you are looking at the two images side by side.  So you can get away with it! Use the "Stretch horizontal" parameter in the dialog of Figure 4 to see how wide you stretch your image without it looking wrong.  Figure 7 shows last image stretched 100% (2X the original width), and it doesn't look bad.  In this dialog, the value 0 means no stretching, i.e., normal.  The value 100 means stretched 100%, i.e., twice as wide.  You stretch by as much as 200% (three times as wide).   Figure 7 – Preparation step #3: Stretch horizontally as much as you can get away with (100% in this case), to increase the width of panorama and make room for camera motion.   The dialog of Figure 4 also has parameters to darken the sides and top and bottom of the image, as described in Background images.   With a wider panorama, you have more room on the edges to fade to black gradually.  Figure 8 shows the result.   Figure 8 – Preparation step #4: Set darkening parameters (see parameters in Figure 4).   The parameters of Figure 4 also shift the picture down to align the horizon in the simulated view with the horizon in the image.  That sets you up for changing the grass to reflective water by "Scenery > Landscape and water > Add water everywhere".  Alternatively you could turn the ground off with the checkbox at the bottom of the dialog, which would let the original water of the image show through, but obviously that water isn't animated and doesn't reflect the fireworks.   Figure 9 – Preparation step #5: Do "Scenery > Landscape and water > Add water everywhere" if the scene is over water.   At this point, your background image is ready for making a video with camera motion.  The next step is to align the launch positions with the background image.  As a reminder, before working to align the positions, please turn on "File > Render settings > Use standard aspect ratio (letterbox)" to make your editing view reflect what will be shown in the video. To get the proper foreshortening of fireworks in the distance, you need to move the launch positions back into the scene to the approximate distance from the camera that they would be if the scene had 3D models for the structures.  In this example, the bridge seems to be about 300m away from the camera point of view, so just go into top view and slide the positions back about that far.  Also stretch the line out ("Positions > Arrange positions > Into line") to separate the positions from each other by the proper distances (total distance of 800m in this case).   Figure 10 – Preparation step #6: Switch to top view, and move the positions back to the distance of the bridge (about 300m in this case), and stretch the width of the line of positions to be the correct width (in this case about 800m total).   Having moved the positions back into the scene, return to the front view and drag the positions up vertically to match the background image, as shown in Figure 11.   Figure 11 – Preparation step #7: Back in front view, drag the positions up vertically to align then with the base of the bridge.   Once the positions are at the proper distance from the camera and align with background image, click on the blue "orbit" control at the bottom of the design view and drag the scene left/right to rotate it.  Get a sense for how far you can rotate it without the positions falling out of alignment from the background image.  You don't need much.  Remember that the purpose of the camera motion is just to make the video seem alive.  Figure 12 shows the starting point for camera motion in this example.   Figure 12 – Preparation step #8: Aim the camera to the beginning point of view, and create a camera key frame at the beginning of the show.   Figure 13 shows the ending camera view.  Add a camera key frame at the beginning of the show for the beginning point of view, and at the end of the show for the ending point of view.  The camera will glide peacefully from one view to the other over the course of the show, achieving the desired result.   Figure 13 – Preparation step #9: Aim the camera to the ending point of view, and create another camera key frame at the end of the show.     Table 1 – Example files Download link Explanation test_bridge_model.fin Example show test_bridge_model_player_compatible.mp4 Player-compatible MP4 video [video width="960" height="540" mp4="https://finale3d.com/wp-content/uploads/2020/09/test_bridge_model_browser_compatible.mp4"][/video] Browser-compatible MP4 video  

The "fill down" technique for assigning firing system addresses is based on the idea of arranging the rows in the script table in the ascending order of your desired addresses, and then quite literally starting with the address of the top row and filling down the addresses in the remaining selected rows, incrementing as you go.  The "Fill down addresses in script window..." dialog shown in Figure 1 has options for specifying the conditions that cause an auto-increment of the module, slat, or pin, making it convenient to select the whole show or a section of the show and then fill down all those selected rows at once, automatically incrementing when conditions change, such as incrementing the module upon change of position. One wrinkle in the fill down technique for firing systems that support multiple effects on the same pin is that effect rows in the script that are supposed to have the same firing system address (i.e., same module, slat, and pin) need to be sorted contiguously, because if there were any other row with a different address separating them in the sequence, then the addresses would necessarily be incremented.   Since sorting the desired same-address rows contiguously may not be possible while maintaining the sort sorted order you are aiming for, the "Fill down addresses in script window..." dialog has a feature that comes to the rescue: the "Backfilling allowed" checkbox.   Figure 1 – The "Backfilling allowed" checkbox enables re-using pins from earlier in the fill down sequence.   Figure 2 illustrates a circumstance requiring backfilling.   If you want to sort addresses by "Position then Event Time" but allow effects at different positions to share pins if they are at the same time, there's no way to do that without backfilling.  Figure 2 shows the result of filling down with addresses sorted by "Position then Event Time" and no incrementing conditions other than the implicit incrementing condition that pins have single event times.   Figure 2 – Sorted by "Position then Event Time", every row has different event time from the previous row and therefore gets an incremented address.   You could avoid the problem of Figure 2 by sorting with Event Time first (e.g., "Event Time then Position") but that might not be the sort you want, and usually isn't since other sorting criteria like Angle and Size are generally more useful than Event Time. Checking the "Backfilling allowed" checkbox allows you to use any sort you want, and each row will re-use earlier pins in the fill down sequence whenever possible, up to the "Max e-matches per pin" limit you set in the dialog (See Figure 1 again).  The result of addressing with backfilling is shown in Figure 3.   Figure 3 – With backfilling, the addresses increment according to the sort with the exception that earlier pins are re-used when possible.    

Many kinds of single-shot racks hold multiple sizes of effects.  If you have a wide range of small caliber effects you may want to limit a rack to a range of sizes, to separate your large single-shot effects from your small single-shot effects, for example.  The min/max size fields in the rack specifications support this constraint. Figure 1 – Racks like the PyroLamas rack shown here can hold multiple size effects   To create a rack definition with a min/max size constraint, do “Racks > Create rack” and set the "Size min" and "max" fields, specifying the sizes in millimeters or inches.  Generally you should leave the per-row size specifications blank to avoid requiring a specific size, but if you wanted to configure the rack to support a min/max range of sizes in most of its rows but only specific sizes within that range for some of its rows, you can specify specific sizes for any rows that you want.   Figure 2 – If you specify a min/max size range, then leave the per-row size specifications blank.