This section contains notes on some of the terms that are translated to other languages to help the translators making the translation files. Table 1 – Explanations Phrase to be translated Explanation ||Fancy angle colors The word "Fancy" generically means the feature or setting does something special that is too hard to describe more precisely in a small number of words. Fancy is not a standard industry term. This particular example refers to a setting for the print format of labels. The "Fancy" option changes the colors of the text depending on whether the angle is left or right. ||Paste special "Paste special" refers to copy/paste operations. Normally when user presses control-v the paste operation pastes whatever is in the copy buffer, but there are some "special paste" operations like "Paste at original times" or "Paste events only" that do something different from normal paste. The word "special" is similar to "fancy" in that it simply means the function is doing something different from normal. ||Filter syntaxnred : search for the substring "red" in any fieldn-red : search for NOT redn... This long phrase is a help dialog that explains the syntax of search phrases that the user can type into the search box to filter the effects table. For example, the line, red : search for the substring "red" in any field means if you type the word "red" in the filter box, that will filter the results to effects that contain the word "red" in their description. The next line, -red : search for NOT red shows how to filter for results that DO NOT contain the word red (the minus sign reverses the filter) ||Straight Up "Straight up" is a column in the script window that has a true/false value (true is displayed as a checkmark; false is blank). The value of "Straight up" depends on the angle of the effect. If the effect is aiming straight up into the sky, then the value of the "Straight up" field is true. This field is used for addressing priority. Sometimes people want to sort straight-up effects before or after angled effects, for example. ||Pan The Pan column is the angle of the effect around the up-axis. The Pan, Tilt, and Spin column together are the three Euler angles that define angle of the trajectory. Pan is the angle around the up-axis. Tilt is the angle forward/back. Spin is the angle around the trajectory axis itself.  Since Pan, Tilt, and Spin refer to different angles, it is important that they translate to different terms.  If the terms do not exist in a language, leave them in English. ||Sequential across rows This is a term that relates to pre-wired racks.  It means the pin numbers are sequential going across the rack rows, i.e., pin number 1 is the first pin of the first row, pin number 2 is the first pin of the second row, etc. ||Sequential across rows, half and half Like the last term except it takes two sets of pins to cover all the tubes in the rack.  The first set is like the last term, and the second set picks up in the middle of the rack rows and continues.  Each set of pins would be connected to a different firing module or slat. ||Sequential by rows Analogous to the last terms, except the pin numbers progress along each row before advancing to the next row, i.e., pin 1 is the first pin of the first row, pin 2 is the second pin of the first row, etc. ||Sequential by rows, half and half Analogous to the previous terms. ||Sequential for each row Each row starts with pin 1 and goes to pin N (if the row has N tubes). ||Aiming in to up This is an option in the "make into fan" dialog, that operates on a list of selected effects that are sometimes arranged in a line/front of positions. In this option, the first effect is angled toward the center of the front of positions, and the last effect aims straight up. ||Aiming out to up This is another option like the last, in which the first shot angles outward, away from the center of the line of positions. ||Aiming up to in Another option in the "make into fan" dialog, first selected effect aiming up and last selected effect aiming to center. ||Aiming up to out Another option in the "make into fan" dialog. ||Angle convention Some people use the convention that an angle of 0 = up. Others use the convention that 90 = up. During import, the "Angle convention" is an option for the user to choose. ||Angles First When addressing a show, some companies like to assign addresses to the angled effects before the straight up effects, so this is one of the sort options in the addressing dialog, like "Size" or "Effect Time". ||Angles Last Another sort option in the "Addressing > Address show" dialog. ||Side This means "side view". It is the label on one of the yellow camera buttons on the right side of the 3D window. Try clicking on this button, and the point of view will change to view the scene from the side. ||EmitCurve The word "EmitCurve" is a technical term for the effect editor. It describes the rate of emitting spark particles. The reason the term is "EmitCurve" instead of "EmitRate" is that the rate is not constant. It is a function that may start off fast and taper off at the end, for example. The "curve" is the function that determines the emit rate and how it changes.   Translators have asked about the context in which the word "Fancy" is used, because it is a strange use of the word. The Figure 1, below, shows the dialog for customizing labels. The "Fancy" options are some of the formatting options that use different colors depending on the values displayed. Figure 1 – "Create or edit labels template" dialog from blue gear menu of script window.  

Half of the world's fireworks display companies count chains of shells as one unit per chain; and the other half count chains of N shells as N units. The distinction comes into play when importing and exporting shows, and when updating show product quantities to or from sales orders in Finale Inventory. Device quantities shown in the Finale 3D tables Finale 3D makes the meaning of displayed quantities explicit by using the term "Devices" in the user interface, which is unambiguous. A device is distinct physical item, like a shell, that cannot be easily divided into components. Shells, cakes, cylinder shells and even peanut shells are considered single devices. Chains are not. So, in the effect table or script table in Finale 3D, the Devices column always represents the number of shells for chains. Aside from the count distinction, designers often want to represent a chain as a single row in the script, as opposed to one row per shell. Finale 3D supports this with the option "Show one row per chain" in the gear menu of the script window. With that option turned on, each chain is represented as a single row; the Devices column shows the total number of shells in the chain; and the "Angles" column shows a representation of all the angles of the shells, such as \|// for a fanned out chain of 5. The printed reports also include an option to consolidate chain rows into single rows, analogous to the "Show one row per chain" option on the script table itself. Figure 1 – Option to show chains as single rows in the script   The menu option, "Show > Show settings > Draw chains on timeline as multiple rows" is a related setting in Finale 3D that controls whether chains are drawn as single horizontal lines on the timeline with multiple break indications, or multiple horizontal lines, one for each shell.  The default for this setting is OFF, since designers usually want to see chains on the timeline as a single line, to keep the timeline simpler. Other chain related information shown in the Finale 3D tables No matter whether anyone counts chains as one-unit or N-units, we can all agree on the meaning of the term device, and therefore we can all agree that the information shown in the Devices column in the tables in Finale 3D is correct and unambiguous. However, the "Price" column and the "Used" column in the effects table show information for chains that does depend on the one-unit versus N-units distinction. If you consider a chain to be one-unit, then your price of the chain part in the effects table would be the price of the whole chain. If you consider a chain to be N-units, then the price would represent the price per shell. Finale 3D has no way of knowing what you mean, so it provides the option, "File > User settings > Chain price is for entire chain" for you to declare your meaning. Based on this setting, Finale 3D will re-calculate the displayed price per device in the script table and in the simulation window. If the chain price is for the entire chain, and you insert a chain of 5 shells into the show, then the price per shell is just 1/5th the chain price from the effect table, so that 5 times the price per device correctly equals the price for the entire chain. For Finale 3D to make this calculation, the Devices column in the effects table contains the number of shells per chain. This field corresponds to the "Chain number of devices" field in Finale Inventory, as discussed below (if you are using Finale Inventory). Figure 2 – Chain price and used count settings   The Used column in the effects table shows the number of units used in the show. Is a chain a single unit, or is a chain of N shells N units? The setting "File > User settings > Chains count as one unit in the 'Used' column" enables you to declare the meaning of units. If you set chains to count as one unit, and you insert two chains of 5 shells each into the show, then the Used column will show the number 2, not 10. The quantity shown in the Used column is particularly important, because you may choose to filter the effect window to show only the effects that have remaining stock after subtracting Used from "Available", or subtracting Used from "On Hand" (filter options are available from the "Select layout template" option in the gear menu of the effect window). For these numerical comparisons to make sense, the units of the Used column must match the units of the Available or On Hand column, which comes back to your decision of how you represent quantities of chains in your inventory management.  So for this reason, please make sure the "File > User settings > Chains count as one unit in the 'Used' column" setting is correct. The "Quota" column in the effects table is a field for you represent the quantity of each part that you have allocated to be used in the show. You can import quota values from a packing list CSV ("File > Import > Import quotas..."), or you can update the quota values directly from a sales order in Finale Inventory ("Effects > Finale Inventory > Update quotas from sales order..."). Of course you can also just manually enter the quotas. No matter how the quotas come in, though, their meaning with respect to chains is whatever your definition is, one-unit or N-units. As with the Available and On Hand columns, you may filter the effect table on the basis of a comparison of Used and Quota, so it is important that the Used column matches your meaning. Also, the user interface colors the Used and Quota cells as red or white or green depending on whether you've used too many in the show, just right, or still some to go. Updating sales order item quantities in Finale Inventory based on quantities in the show design The menu item "Effects > Finale Inventory > Update sales order from used quantities..." updates a sales order in Finale Inventory based on the quantities in the show design. This operation is another integration point in which the distinction between chains counting as one-unit or N-units matters. In your inventory management account on Finale Inventory, chains will count as one-unit or N-units according to your own definition. In Finale 3D, the show design has an unambiguous count of devices, but how is the conversion to be made from device count to chain count? Finale Inventory has two fields that enable you to declare your meaning of chain count. By specifying these two fields, you give Finale Inventory enough information to convert devices to chain count according to your meaning. The first field is in the Finale Inventory configuration page on the Finale 3D website ("finale3d.com > My Account > Finale Inventory Settings"), as shown in Figure 3. Figure 3 – In your Finale Inventory, do chains count as one-unit or N-units?   If chains count as N-units, then the conversion from devices to units is easy, because devices = units. However, if chains count as one-unit, then the chain count for any particular chain part is the number of devices divided by the number of shells per chain of that part number. To make that calculation, Finale Inventory or Finale 3D needs to know the number of shells per chain for each chain part in your inventory. In your Finale Inventory account, in the "Application settings > Product" section from the home page, you can enable the "Chain number of devices" field as one of the product properties.  This field corresponds to (and synchronizes with) the Devices column in the effects table in Finale 3D. Figure 4 – Turning on the "Chain number of devices" field in Finale Inventory   Having enabled the "Chain number of devices" field in Finale Inventory, you can import or manually enter the number of shells per chain in the product properties of the chains in Finale Inventory. With that, you've given Finale Inventory and Finale 3D the necessary information to make the conversion of the chain quantities in your designed shows into your inventory account, no matter what your definition is for chain counts, one-unit or N-units.

Slats, virtual slats, and splitter boxes all refer to the same type of firing system hardware -- a box or rail with electrical terminals on it. They only differ with respect to the representation of addresses in the exported firing system script files, which varies from firing system to firing system. Thus depending on what firing system that you use, you will probably use only one of the three terms -- slats, virtual slats, or splitter boxes -- whichever term makes sense for your firing system. The basic idea of slats, virtual slats, and splitter boxes is to partition the modules' electrical terminals (pins) onto multiple boxes or rails that can be located at different physical launch positions, rack clusters, or racks. A single cable or wireless connection connects the controller to the module; multiple cables extend from the module to its boxes or rails of terminals located at different physical locations; e-matches extend from the terminals to the effects being ignited. Thus by way of using the boxes or rails of terminals, a single module can serve multiple physical locations without requiring e-matches or scab wiring to bridge between them. Some firing systems, such as Pyrosure or FireTek, incorporate the idea of using boxes or rails of terminals integrally in the design of the firing system itself, and represent the group of terminals in the script file explicitly as a two-part rail address, such as "1-B" for module 1, slat B. We call these groups of terminals "Slats". Other firing systems support external hardware that partitions the terminals into rails or boxes arbitrarily but do not explicitly represent the partitioning in the script file format itself. We call these groups of terminals "Virtual Slats" (see Virtual Slats). Addresses of virtual slats are represented with two-part rail addresses in Finale 3D, just like non-virtual slats, but the two-part rail addresses and their pin addresses are converted back into the corresponding sub-range of pins of the parent module in the exported firing system script file. For example, you can partition the 32 pins of a FireOne module with module number 1 into four 8-pin groups that would be represented in Finale 3D as 1-A, 1-B, 1-C, and 1-D, each with pins numbered 1-8. In the Finale 3D script table you would see two-part rail addresses and pin addresses in the range 1-8, but in the exported FIR script file those addresses get converted to one-part module numbers, and pins in the range 1-32 (pins 1-8 of group 1-C would be translated to pins 25-32 of module 1 in the FIR script file). The third term, "Splitter Box", simply refers to slats that partition the terminals into pre-defined sub-ranges of pin addresses that are not explicitly represented in the script file format itself.  Explo and Galaxis splitter boxes are examples of this third category of hardware.  As you can see from these definitions, there's not much difference between virtual slats and splitter boxes.  The different terms simply reflect the fact that you can create any kind of partitioning you want for a firing system using virtual slats, whereas splitter boxes refer to pre-defined hardware listed as options in Finale 3D's user interface that you can choose from. Figure 1 – Splitter boxes like this Galaxis device may display the absolute pin numbers that the box is configured for.   While slat-based addresses in Finale 3D are always displayed as three part addresses (Module-Slat-Pin) with the pin relative to the slat, it may be the case that your physical slat or splitter box hardware displays absolute pin numbers relative to the module instead of relative to the slat, like the Galaxis splitter box shown in Figure 1.  If that's the case, you may want to create custom labels in Finale 3D using the "Pin Absolute" field or the "Module/Pin Address" field, as described in Labels basic instructions. Given these definitions, you can understand why Finale 3D uses the term "Rail Address" in the script table and in other places in the user interface instead of "Module Number".  The rail address specifies both the module and slat (two-part addresses) if the firing uses slats or if you are using virtual slats, whereas module number just specifies the module.   If your firing system doesn't have slats and you aren't using virtual slats, then rail address and module number are the same thing.   Table 1 – Definitions Term Definition Slat A distribution box or rail for a module's electrical terminals, which is explicitly represented in the firing system's script file in a two-part rail address Virtual slat A user-defined distribution box or rail for a module's electrical terminals, which is not explicitly represented in the firing system's script file Splitter box A pre-defined distribution box or rail for a module's electrical terminals, which is not explicitly represented in the firing system's script file Rail address A two-part or one-part address like "1-B" or "1" that specifies both the module and slat (a two-part address) if slats or virtual slats are required, or just the module number otherwise (one-part address) Module number The one-part address identifying a specific module Pin Absolute An optional field in custom labels that converts pins relative to the slat into pins relative to the module Module/Pin Address An address consisting of module and absolute pin numbers (converting the pin from slat-based to module-based if necessary)   The most common need for slats, virtual slats, and splitter boxes is to partition a module's pins into boxes or rails that can be located at different launch positions, but you might also want to locate the slats at different rack clusters or at different racks themselves within a launch position.  The addressing system of Finale 3D supports all these use cases  with the same mechanism: addressing constraints. Slats at different launch positions Suppose you have one Explo module with 70 pins that are distributed to three different launch positions using three splitter boxes with twenty pins each (10 pins being left over, unused). It would be important when addressing the show to apply the constraint that each splitter box is restricted to serving a single launch position, for otherwise you might have e-match wires running from position to position. But it would be too restrictive to constrain each module to serving a single launch position, because that would defeat the whole idea of using splitter boxes to distribute the module’s pins among multiple positions. In this scenario, you would use the addressing constraints section of the "Addressing > Address show..." dialog to specify that slats are restricted to a single position, but modules are not restricted to a single position.  You would address the show with the firing system = "Explo", and module type = "Explo 3 x 20K" to indicate you want to use the Explo 20-pin splitter boxes.  Based on these parameters, the addressing function will assign as many splitter boxes as necessary to your three launch positions and will ensure that no e-matches are required to bridge from one position to another. In practice, large shows that use splitter boxes typically don't use splitter boxes everywhere.  They use splitter boxes for certain positions that are close together and use non-splitter modules for the other positions.  To address a show like this, you need to create two separate sets of addressing constraints for the two kinds of positions -- those that use splitter boxes, and those that do not.  The Finale 3D menu item "Create addressing blueprint..." presents a dialog very similar to the "Address show..." dialog, enabling you to create sets of addressing constraints called "Addressing Blueprints."  Create two blueprints, one with slats restricted to a single position and modules unrestricted (for the positions using splitter boxes); the other with modules restricted to a single position and slats unrestricted (for the positions not using splitter boxes).  Right-click on the positions and edit their position properties to assign the appropriate addressing blueprint to them, and set their module type to "Explo 3 x 20K" for the splitters or "Explo 70K" for the non-splitter modules.  Do the menu item "Addressing > Address show using blueprints assigned to position..." to address the show.   Table 2 – Blueprint for slats at different positions connected to the same module Modules constrained to same (no constraint) Slats constrained to same Position   One more consideration remains.  A large show may have multiple groups of positions that are in proximity with each other, but the groups themselves may be far apart.  If you use splitter boxes for all these positions, the slat constraints and choice of module type will correctly indicate splitter boxes and ensure no e-matches bridge between positions, but there's no guarantee the splitter boxes associated with the same module are anywhere near each other.   To keep the splitter boxes associated with any individual module within the same group of nearby positions, you need to indicate what the groups are by right clicking on them and assigning a group name to the "Section" field in the edit position properties dialog.  Each group of nearby positions should have the same section name, which can simply be a number or letter or any text string, whatever you want to call it. If you look closely at the "Address show..." dialog or the "Create addressing blueprint..." dialog, you will see that the module constraints line says, "Each module is restricted to a single section and..." (emphasis added).  Modules are automatically restricted to single sections, so you don't need to change your addressing blueprints at all.  Assigning your positions to different sections to indicate their groups will ensure that splitter boxes will only refer to modules used within their group of positions.   Table 3 – Blueprint restricting modules to serve a single position each Modules constrained to same Position Slats constrained to same (no constraint)   Slats at different rack clusters in the same launch position Slats can also be used to distribute pins to different rack clusters or racks within the same position.  If you are planning to use Finale 3D for rack layout, which is optional, please see Rack layout basic instructions to familiarize yourself with the rack layout capabilities. Suppose again that you have one Explo module with 70 pins that are distributed using three splitter boxes with twenty pins each (10 pins being left over, unused), but imagine that each splitter box was to attach to a group of racks (called a "Rack Cluster").  When addressing the show you would need to apply the constraint that each slat is restricted to serving a single rack cluster, but each module is only restricted to serving a single position.  The settings are shown in Table 4.  As in the previous scenario, you would also set the module type in the "Addressing show..." dialog or the edit position properties dialog to "Explo 3 x 20K" to indicate you want to address the positions using splitter boxes.   Table 4 – Blueprint restricting slats to serve a single rack cluster each Modules constrained to same Position Slats constrained to same Rack cluster   Slats at different racks in the same launch position Distribute pins to different racks is the same as the rack cluster scenario, except the slat constraint is just "Rack" instead of "Rack Cluster" as  shown in Table 5.   Table 5 – Blueprint restricting slats to serve a single rack each Modules constrained to same Position Slats constrained to same Rack   Associating slats one-to-one with racks or rack clusters By constraining slats to the same rack, you are ruling out the possibility that a slat can have e-matches extending to multiple racks, which might not be near each other.  However you aren't ruling out the possibility that multiple slats can have e-matches to the same rack.  Imagine you had a single-shot rack with spaces for 24 tubes and you were using Explo 20-pin splitter boxes.  If you address the show with the constraints of Table 5, you might end up filling all 24 spaces with effects and using two slats (splitter boxes) to do it, the first slat covering the first 20 effects and the second slat covering the remaining 4 effects.  Since you are constraining slats to a single rack, the second slat's remaining 16 pins will be unusable for any other racks and thus for any other effects.  They will lie unused. Depending on the availability of firing system hardware and racks, you may view it as wasteful to leave 16 pins of a 20-pin splitter box unused.  You might prefer to leave 4 tube spaces in the single-shot rack unused, if that meant that your 20-pin splitter box would be fully utilized on a single-shot rack of its own.  You could implement this trade off by adding the constraint that each rack is constrained to a single slat.  The combination of the rack constraint and the slat constraint forces the slats and racks to associate one-to-one -- each rack would have one associated slat, which would serve only that rack.  The constraints are summarized in Table 6. Associating slats one-to-one with racks or rack clusters can facilitate integrating firing system slats into pre-built assemblies of racks or rack clusters.  If you know that racks or rack clusters will be associated with a single slat no matter what, then you can integrate the slat hardware physically with the rack assemblies in advance, before designing or addressing the show, and re-use the assemblies over and over again without needing to adapt them to the addressing requirements of any particular show.   Table 6 – Blueprint associating slats and racks one-to-one Modules constrained to same Position Slats constrained to same Rack Racks constrained to same Slat    

To create and export a script for the Explo firing system, please follow these steps: Address the show ("Addressing > Address show"). Export the script ("File > Export > Export firing system script file…"). Step 2 creates the SHW script file.  The file format details are described in this section.   Figure 1 – Explo firing system   The Explo SHW script can be imported and exported from Finale 3D.  It is a CSV file with SHW filename extension.  The SHW file is both a direct representation of what the user sees when editing a script in the Explo software, and also a firing system format, so the format is more flexible than most firing-system-only formats, to enable the user to represent script rows in the most convenient and readable representation (see "What rows represent" in Table 2, below).   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text .SHW Code Page 1252 Tab LF The script contains rows of information including module, pin, and ignition-time and other information.  Multiple effects on the same module and pin at the same ignition time can be combined as a single row, or can be listed as separate rows.  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 by effect time. What rows represent Each row contains firing information associated with a shot.  Although the rows are sorted by effect time, any single row may contain multiple effects ignited by the same module and pin, at the event time.  Coalescing by unique module-pin or module-pin-event-time is not required.  For example, a chain of five shells can be one row, or can be five rows.  A pair of shells shot together from the same position can be one row, or two. Rows with module addresses corresponding to Explo Flamer units have a special meaning.  Since flame projector units do not require a pin number to identify an electrical terminal, the pin number in the row is available for another use.   For Explo Flamer units, the pin number represents a pre-defined flame program, or macro, that causes the flame to project at a specific angle or to animate across a sequence of angles. Header and end-of-show line The file contains a single header row with the column names, in the same format as the CSV data rows themselves. After the data rows, the file contains a final row with all fields blank except the second, which is the last effect time in the show, and the fourth, which is the word "Ende". Multi-hit pins Non-pyro effects like flames and relays can be triggered multiple times on the same module-pin address. 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. Special characters The characters ‘ and “ and , and ; and and tab and newline will be filtered out of any text fields. Minimum separation between cues None required; 1/100th second resolution supported. Module specifications Supports 99 modules (numbered 1-99), each module with 30 or 70 pins (numbers beginning with 1). Also supports "Splitt" boxes that partition the range of pins in separate boxes that can be located at different positions (see below).  The full list of Explo module types in Finale 3D is: Explo 30K, Explo 20K, Explo 2 x 20K, Explo 3 x 20K, Explo 2 x 20K Offset 10, Explo 3 x 20K Offset 10, Explo Flame Unit. "Splitt boxes" Explo firing systems support partitioning a device’s range of pins into 20-pin “splitt boxes.” Finale 3D supports splitt boxes using virtual slats, so you can take advantage of Finale 3D’s powerful addressing and racking features for reasoning with constraints relating to slats being at different physical locations (see Slats, virtual slats, and splitter boxes).Suppose you have one module with 70 pins that are distributed to three different launch positions using three splitt boxes with twenty pins each (10 pins being left over, unused). It would be important when addressing the show to apply the constraint that each splitt box is restricted to serving a single launch position, for otherwise you might have e-match wires running from position to position. But it would be too restrictive to constrain each module to serving a single launch position, because that would defeat the whole idea of using splitt boxes to distribute the module’s pins among multiple positions. Using virtual slats to represent splitt boxes allows you to arrange slats (splitt boxes) at various positions while having their module number and pin numbers still refer to the correct pin range of the parent module. In the Finale 3D script, splitt boxes’ Rail Addresses are two-part addresses, such as 1-A meaning module 1, first splitt box; or 1-B meaning module 1, second splitt box. The pins of each splitt box are numbered 1-20 in the Finale 3D script, but are converted to the corresponding 20 pin sub-range of the parent module’s range of pins 1-70 when exported to the SHW file. If Finale 3D, if you use the "Explo 2 x 20K" module type, its rail and pin addresses will be represented in the script window as rail address "1-A" and pin addresses 1 through 20 for the first splitt box, then "1-B" and pin addresses 1 through 20 for the second splitt box, etc., but will be translated to module address "1", pin addresses 1 through 40 in the SHW file. The Finale 3D module types "Explo 2 x 20K Offset 10" and "Explo 3 x 20K Offset 10" are the same as "Explo 2 x 20K" and "Explo 3 x 20K" except the pin numbers in the exported SHW file begin at 11 instead of 1. Flame units To design a show with Explo flame units using Finale 3D, please address the show with "Explo Flame Unit" module types if the show is entirely flame effects, or assign "Explo Flame Unit" as the module type of specific positions (by editing their position properties) if the show is partially flame effects and partially pyrotechnics. Any single position will be entirely flame or entirely pyrotechnic, depending on its module type. From the effects window, add pyrotechnic effects to the pyrotechnic positions, and add flame effects to the flame positions. Explo X2 Flamer units support 66 pre-defined flame programs, or macros, that cause the flame to project at a specific angle or to animate across a sequence of angles. The Generic Effects collection in Finale 3D includes 66 pre-made effects corresponding to the Explo flame programs, GFX9001 to GFX9066. These Explo effects all have realistic simulations and correct parameters representing the flame program numbers that get carried through into the script when you address the show and into the exported SHW file when you export. Thus, to design a show with Explo flame units, all you need to do is specify the module type is "Explo Flame Unit" and script using the pre-made Explo effects from Generic Effects; then address the show and export the SHW file. The show simulation will be realistic, and the exported SHW file will contain the flame program numbers. In the SHW file, the pin number in the "Box/Nr" field represents the flame program number for flame units. The pin number field is available because the flame units do not have physical pins. When you address the show, Finale 3D assigns module and pin numbers for the pyrotechnic module types, and assigns module and program numbers for the flame unit module types. The program numbers, stored in the "Pin" column in Finale 3D and the Box/Nr field of the SHW file, come from the "Custom Part Field" of the effects. As a convenience to the user, the Generic Effects with part numbers GFX9001, GFX9002, GFX9003, etc., happen to correspond to flame programs 1, 2, 3, and so on; but the actual data field in those effect definitions that specifies the flame program number is the Custom Part Field, not the part number.  Please unhide the Custom Part Field column in the effects window to see. After the header, each row in the script has a number of fields separated by tab.  The names of these fields and their descriptions are the following:   Table 3 – Specifications of script fields Field name Description Box/Nr (Exported and imported) The module (box) and pin (post) or Explo Flamer program number ( 1-66) of the shot, separated by slash. Explozeit (Exported and imported) The break time of the shot, in the format MM:SS.DD, where MM is the number of minutes formatted as two or more digits; thus capable of representing shows longer than 99 minutes. Abstand Zündzeit (Exported only) The delay to the next firing row, in the format MM:SS.DD, where MM is the number of minutes formatted as two or more digits; thus capable of representing shows longer than 99 minutes. Effektbezeichnung (Exported and imported) The effect description. (string, 80 characters max) Stz. (Exported and imported) The prefire time, in the format 0,0 (comma radix point). Efz. (Exported and imported) The duration of the effect, in the format 0,00 (comma radix point). Efg. (Exported and imported) The hazard field. (string, 80 characters max) Stop (Exported only) Finale 3d leaves this field blank. Stk. (Exported and imported) Quantity. Finale 3d writes the total number of devices represented by the firing row. Beschreibung (Exported and imported) Comment field. Finale 3d writes a graphic indicating the angles of the shots, such as ///. (string, 80 characters max) Position (Exported and imported) Position name. When importing a SHW file, if the Position field is blank then Finale 3D will construct a position name from the module number in the Box/Nr field, e.g., "Box-11". (string, 80 characters max) Steighöhe (Exported only) Finale 3d leaves this field blank. Größe (Exported and imported) Size. Finale 3d writes the part's Size into this field, including its units, e.g., 2.5" or 30mm. Etk. (Exported only) Number of labels to print. Finale 3d writes the total number of devices, same as "Stk." field. Effekttop (Exported only) Finale 3d leaves this field blank. Gruppe (Exported only) Finale 3d writes the value in the Track field if it is a valid value. (integer, 0-999) Bereich (Exported only) Finale 3d leaves this field blank. Winkel (Exported and imported) Angle. Finale 3d writes the shot angle, formatted as an integer, followed by the degrees character, i.e., 0° (character 0xB0 in Code Page 1252 encoding). If the script row represents multiple shots, the angle is that of the first. Pos. (Exported only) Finale 3d leaves this field blank. Use of this field is deprecated by Explo, though in practice it is sometimes used for the launch position notwithstanding the guidance from Explo (understandably, given the name). (blank) (Exported and imported) Artikel Ref. Finale 3d writes the Part Number. (string, 80 characters max)   Importing SHW files You can import a SHW file into Finale 3D from the "File > Open..." menu item, simply by selecting the SHW file to import.  Finale 3D will construct a show from the fields in the SHW file indicated in Table 3.   SHW files do not contain 3D coordinates of the positions, so Finale 3D lays out the positions in the 3D world in a reasonable default pattern that takes into account the size of effects at each position.  Finale 3D constructs visual simulations for the effects directly from the effect descriptions themselves, also taking into consideration the size and duration fields if provided. For importing shows that include Explo Flamer effects on their own or in combination with pyrotechnic effects, Finale 3D processes the imported data from the SHW file to expand the rows with flame effects into script rows in Finale 3D that have the correct visual simulations for the flames.   Based on the Box/Nr field, Finale 3D can infer the Flamer program number (1-66) and can construct a matching simulation for the flame animation.  But first, Finale 3D first must determine what rows in the show are flames, and what rows are pyrotechnic effects.  Finale 3D follows this logic to make a good guess: Since the SHW file does not contain any reliable explicit indication of what rows are flames versus what rows are pyrotechnics (the descriptions sometimes include the word "flame" for flames but often they do not), Finale 3D examines the full show and attempts to determine what modules (boxes) are flames based on their pin outputs.  If the module has at least two rows with the same pin number at different times, then the pin is not a pyrotechnic effect because it couldn't ignite an e-match twice.   If the pin is not a pyrotechnic effect, it is probably a Flamer program number (1-66).  If the pin is a Flamer program number, then the module must actually be a flame unit.  Therefore all the pins on that firing module should be interpreted as Flamer program numbers. Having determined what rows are flames, Finale 3D takes takes the following steps to process the flame rows: Change the Module Type of the imported row to explo_flame. Change the Custom Part Field of the the imported row to the program number (1-66). Change the Description to the corresponding description of the program's animation, looking the description up from a table of 66 values. Change the Part Number of the imported row to the corresponding effect in Finale 3D's Generic Effects collection. Erase the angle field, because the program subsumes the angle. Change the Devices field to zero, since flame effects themselves are not devices. Change the VDL field to the corresponding VDL animation description that matches the program number.   Examples An example script is shown below.  Notice the last two rows are at the same event time but have different modules and therefore cannot be combined into a single row. Exported from Finale3D test_explo.mp3 Box/Nr Explozeit Abstand Zündzeit Effektbezeichnung Stz. Efz. Efg. Stop Stk. Beschreibung Position Steighöhe Größe Etk. Effekttop Gruppe Bereich Winkel Pos. 1/1 00:05.00 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-01 2" 1 G2SH1003 2/1 00:05.10 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-02 2" 1 G2SH1003 3/1 00:05.20 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-03 2" 1 G2SH1003 4/1 00:05.30 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-04 2" 1 G2SH1003 5/1 00:05.40 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-05 2" 1 G2SH1003 6/1 00:05.50 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-06 2" 1 G2SH1003 7/1 00:05.60 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-07 2" 1 G2SH1003 8/1 00:05.70 00:00.10 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-08 2" 1 G2SH1003 8/2 00:05.80 00:00.00 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-08 2" 1 G2SH1003 9/1 00:05.80 00:00.00 Green Chrysanthemum 2,2 1,00 shell 1 | Pos-09 2" 1 G2SH1003 00:05.80 Ende Figure 1 – Example Explo SHW script   Table 4 – Example files Download link Explanation test_explo.shw Example exported file  (CSV) test_explo.fin Example show file demo_explo_flame.shw Example flames exported file demo_explo_flame.fin Example flames show file demo_explo_flame.mp4 Render example of flames

Some applications may require combining a simulation video produced in Finale 3D with other video created in other applications.  Video editing software tools like Adobe Premiere provide all the functionality to combine videos, but you still need to create the video assets in a suitable format to be combined. There is a common misconception that overlaying fireworks simulations from Finale 3D onto other video backgrounds would require a transparency layer (also called an alpha channel, or chroma key) to extract out the simulations to apply over the background.  However, fireworks simulations are predominantly light, so alpha blending is not the best operation for combining them onto background scenery.  The reason is, light should never darken a scene, but if you use alpha blending, the partially transparent edges of the sparks may actually be darker than the background or even nearly black.  Therefore even if they are mostly transparent, they actually darken the scene.  The result is black edges around sparks. A better operation to combine a fireworks simulation over a background is called "additive blend" or "linear dodge".   This operation strictly adds the light from the fireworks simulation to the background.  The fireworks sparks therefore only brighten the background.  And any black area in the fireworks video has no effect on the background. In Adobe Premiere, the operation is called "Linear Dodge (add)", in this menu:   Figure 1 – Linear dodge (add) is the best mode for overlaying fireworks simulations   To generate the video assets in Finale 3D, you need to make everything other than the fireworks themselves entirely black.  It also may yield a higher quality result or be more convenient in your editing software to save the assets from Finale 3D as a png sequence instead of an encoded video.  Figure 2 shows the render configuration settings dialog for creating video assets in Finale 3D to be combined with others.  Notice the zero brightness scales on everything other than fireworks.  The output format at the top is selected to produce a sequence of png images, such as YOURNAME.000000.png, YOURNAME.000001.png, etc. Figure 2 – Render configuration in Finale 3D for producing the video asset to be overlaid   Camera field of view The camera vertical field of view for rendered videos is 60 degrees.  Please check the "Standard aspect ratio in edit mode (letterbox)" field at the bottom of the render configuration to ensure what you see while editing the scene is the same image ratio as the exported video.  The vertical field of view is the angle defined by the vertical range from the top to bottom of the image.   Coordinate system Positions, models, and cameras all use the same, right-handed coordinate system in which X is to the right, Y is up, and Z is back toward the viewer (out of the screen in the identity orientation).  Position coordinates are relative to models they are attached to, or to the global coordinates otherwise.  ("Origin man" stands at the origin in global coordinates facing the positive Z axis.)  Angles represented as heading, pitch, roll (HPR) can be combined as a composite rotation by rotating the identity orientation by three successive rotations, rotating first by pitch about the global X-axis, then by roll about the global Z-axis, and finally by heading about the global Y-axis, following the right-handed convention for the angles.  Details of the coordinate systems are explained here: Positions coordinate system.    

The Section field in position properties is an implicit constraint that prevents modules from being shared across positions in different sections.  Just like the other module constraint options on the addressing dialogs of the form “Module restricted to single X”, you could imagine the meaning of Section is “Module restricted to single Section”, except it isn’t shown on the dialog because it always applies. Sections are commonly used in large shows with firing systems that have slats.  Imagine a show with 100 positions, and five modules to be shared across those positions with slats at the individual positions.  You may want to organize your positions into five sections for the five modules, to arrange for each module to serve 20 positions that are nearby each other.  To create this organization, select a group of 20 positions that are nearby each other, then right click one of them and do “Edit position properties” from the context menu.  Then section the section to 1 (or “A” or “banana” or any word you want).  Do the same for the second group of 20 positions, assigning them a different section name.  Repeat for all five groups.  After assigning the section numbers, when you address the show, modules will never be shared across section boundaries. Adding section numbers wouldn’t make any difference if you already were using the constraint “Module restricted to single Position”, because if modules are restricted to single positions, then that means they are also restricted to single sections, since sections are just groups of positions.  Most commonly, section numbers are useful when either 1) you are using slats, or 2) your groups of positions are so close together that you allow e-matches from a single module to serve all positions in the section, or 3) you are handling a special circumstance, like using scab wire to connect a position with a lone large caliber shot to the nearest other position with a module. In the slat circumstance (1), the addressing constraints are typically,   Table 1 – “Normal Slats” blueprint for sharing modules with non-piggy back slats Modules constrained to same (no constraint) Slats constrained to same Position   And since there is no Position constraint on the modules, the section number is what prevents the modules from being shared across the boundaries of the groups of positions. In the scenario (2) in which modules serve all the positions and slats aren’t even involved, the constraint options are simply,   Table 2 – “Sharing Modules” blueprint for sharing modules Modules constrained to same (no constraint) Slats constrained to same (no constraint)   Scenario (3) usually uses the constraints of Table 2 for the specific positions involved in the special circumstance, but uses a different set of constraints from a different blueprint for the other positions in the show.  As discussed in addressing constraints, the assignment of a different blueprint to the positions involved in the special circumstance would create an implicit section boundary around those positions, so it is not strictly necessary to further distinguish them with a unique section number, but it is good practice, because you might use that blueprint in other sections of the show also, without intending to group those other sections with the special circumstance positions.

The meaning of "Module restricted to single X" is that every effect fired from the module must have the same value for X, whatever X is.  For example, if you select X = Position, then the meaning is that every effect fired from a given module must be at the same position.  That’s usually what you want, because usually you don’t want effects at different positions fired by the same module, because that would require e-matches or scab wire running between the positions.  Except for a few special values (see Special constraints), the possibilities for X are just the attributes of the effects being addressed. If you add a second constraint, like “Module restricted to single Size” then not only will the module’s wires be restricted to a single position, they will also be restricted to effects with the same size.  This constraint might be useful if your racks for different size effects were far apart, and you didn’t want wires running between the different size racks. If you want eliminate wires between arbitrary groups of racks (“Rack Clusters”), then you can add a Rack Cluster constraint to the modules, as described here: restricting to racks. In addition to the module constraint options on the addressing dialogs, there is an implicit constraint that always applies: “Module restricted to single section”.  An Addressing Group is any group of positions that has the same Start Module Number, Blueprint, Module Type, Section, and Universe -- all of which can be set on the position by right clicking the position and doing “Edit position properties” from the context menu.  The section constraint refers to the addressing group, preventing modules, slats or pins from being shared across positions that are different with respect to Section or any of the other addressing group terms.  If you want to share modules across positions, the positions involved must have the same values for these properties.  See Using the Section field in position properties. The constraints on slats and pins have the same meaning as the constraints on modules, but they apply to the slats and pins.  If the firing system doesn’t use slats, then you can ignore the constraints on slats.  At first blush, you might wonder what the meaning of the constraints on pins is.  In fact, constraints on pins only matters if you allow multiple e-matches on the same pin, which means that you’ve changed the default “Max e-matches per pin” on the addressing dialog from 1 to some number larger than one.  If you do that, then the constraint adds restrictions on the effects shot from the same pin, analogously to the restrictions on the effects shot from the same module.  For example if you add the constraint “Pin restricted to single Size”, then you will never have effects of different sizes being e-matched to the same firing system pin. If you use slats at different positions that are connected to the same module, then the constraint options are required to restrict each slat to a single position whilst NOT restricting the module to a single position.   The “normal” constraints for using slats at different positions connected to the same module are shown in Table 1:   Table 1 – “Normal Slats” blueprint for sharing modules with non-piggy back slats Modules constrained to same (no constraint) Slats constrained to same Position   This table does NOT include a Position constraint on the module, because if it did, then the same module couldn’t feed the slats at the different positions.  The positions do share the modules; they do not share the slats. If the firing system uses piggyback slats, then a different set of constraints is required, as described here: piggyback slats One final observation about constraints may make them easier to remember:  If you add a constraint X to the module, then it is redundant and unnecessary to add it to the slat or pin.  The reason is, any effect fired from a slat or pin is also being fired by the module to which the slat or pin is connected, so that module’s constraints will apply.  If would be impossible to have two effects of different sizes e-matched to the same pin, for example, if the module was constrained to a single Size, even though the pin didn’t have any explicit constraints on it.  

Shows that use firing system slats in some positions and not others require addressing the different sections of the show with different rules.  The Pro and Hobbyist versions of Finale 3D support slats in slightly different ways.  The Hobbyist version uses "Sections."  The Pro version uses "Sections" and also adds the option of using "Addressing Blueprints" which allow for more addressing customization for different sections of the show.  Both the Hobbyist and Pro versions also support slats by manual addressing, of course, which allows any kind of address assignment but which generally requires more work than the automatic functions. The dialogs relating to addressing for slats or modules that fire in parallel are the "Address Show" or "Addressing Blueprint" dialog, for defining the addressing rules, and the "Position Properties" dialog, for specifying which positions the rules apply to and for defining the boundaries within which modules or slats can be shared.   The relevant fields in these dialogs are shown circled in Figure 1 and Figure 2. Figure 1 – The "Address Show" dialog specifies the addressing rules.   Figure 2 – The "Position Properties" dialog assigns section names and addressing rules (addressing blueprints) to positions.   General principles In the sections of the show that use slats, you need the slats themselves NOT to be shared across positions, while the parent modules of the slats ARE shared across the positions.  For example, if positions Front-1, Front-2, Front-3, Front-4, and Front-5 all use slats from the same module, they are all sharing that module, which can be located anywhere, but they are not sharing the individual slats, which are located at the positions in which they are used exclusively.  For this scenario, the basic constraints are, Table 1 – Constraints for sharing modules across positions Modules constrained to same (no constraint) Slats constrained to same Position   By contrast, positions that use pins directly on the modules, would constrain each module to a single position so that wires from the module do not stretch to other positions. Table 2 – Constraints for NOT sharing modules across positions Modules constrained to same Position Slats constrained to same (no constraint)   Some firing systems provide a method of replicating a slat or module with piggyback units that fire in parallel, as if they were wired together.  Finale 3D supports addressing piggy back slats either manually by hand or automatically using blueprints. If you manually assign all the slat and module addresses by hand, you can assign the same module number at multiple positions to represent the fact that the same module addresses are firing in parallel at the different positions.  Usually that would be an error, but in the case of piggyback units, it is not an error.   Addressing the show using blueprints (Pro) The “Address show with blueprints assigned to positions” function (a Pro feature) uses addressing templates (Blueprints) to encapsulate the different rule sets that apply to the different sections of the show.  A section of the show that uses the pins directly on the modules and does not share modules among positions would use the blueprint, or rule set, represented by Table 2.  A section of the show that uses slats at different positions connected to a common (shared) module would use a blueprint represented by Table 3.  A section of the show that uses piggy back slats firing in parallel at different positions would use the blueprint represented by Table 4.  If you are using piggy back slats or modules, you also need to change the "Max e-matches per pin" limit in paragraph 1 of Figure 1 from "1" to as many piggy back slats or modules as are being shared. If the original positions in the show have both piggyback and non-piggyback units, then you need to split the positions into two parts, such as splitting a position named Front-01 into Front-01A and Front-01B, moving all the effects destined for the piggy back slats to A or B.   Assuming you’ve separated the piggy back positions, the next step is to create the two blueprints for the slats: Piggyback Slats, and Normal Slats.  Assign these blueprints to the respective positions, and assign a “Normal Modules” blueprint represented by Table 2 to the positions that use pins directly on the modules. Table 3 – “Normal Slats” blueprint for sharing modules with non-piggy back slats Modules constrained to same (no constraint) Slats constrained to same Position   The Piggyback blueprint has different constraints: Table 4 – “Piggyback Slats” blueprint for sharing piggy back slats Modules constrained to same (no constraint) Slats constrained to same (no constraint)   The final step, after assigning the blueprints to the positions (by right clicking on the positions and clicking “Edit position properties” in the context menu), is to address the show with the function “Address show using blueprints assigned to positions.”   Addressing the show without using blueprints (Hobbyist or Pro) Since the Hobbyist version doesn't support blueprints, you aren't able to assign different rule sets to different sections of the show.  However, you can use the section field to define the boundaries for sharing.  In some cases, that's all you need.   Take for example the scenario in which a section of the show (say, the front positions) share piggy back modules and the other positions do not share modules. In this example, you can select all the front positions, then right click one and do "Edit position properties" to edit the properties of those positions as shown in Figure 2.  Set the section field of those positions to the same name (e.g., "front") so they are in the same section.  Then edit the position properties of the other positions in the show individually, and assign each one of them its own unique section name.  Then address the show using the constraints of Table 4 (no constraints).  Since modules are inherently restricted to the same section (see the text on the first line of paragraph 3 in Figure 1), the front positions in the same section will be allowed to share the same modules, which is what the piggy back modules are doing in reality, while the other positions in their own sections will not be allowed to share modules.

Every display company has a different scheme for arranging its racks, but most companies arrange their racks in groups (“Clusters” in Finale 3D terminology) of some kind.  Generally, companies do not want e-match wires extending between groups of racks, which imposes constraints on the firing system addresses. Consider the example of a display company that uses Pyrodigital field modules with 16 pins, along with wooden racks with 5 tubes each, nailed together in clusters of three racks housing 15 tubes per cluster.  The company attaches a single field module to each cluster. For ease of setup, the company decides that it is willing to let one pin per module go unused, allowing the other 15 pins to match up with the 15 tubes in the rack assembly to which the module is attached.  From an addressing perspective, this company needs to add the constraint that a module is restricted not to a single rack, but to a single rack cluster.   Table 1 – Sort order and constraints for eliminating wires between rack clusters Addresses sorted by Position > Size > Angle Modules constrained to same Position, Size, Angle, Rack Cluster   Addressing the show with these sort criteria and constraints will result in one module per rack cluster, and that module’s 16th pin will go unused to avoid wires running between the rack clusters.  The two screenshots below show the effect of snapping the racks together into clusters before addressing.  Both examples have the same sort criteria and constraints, from the table above.  In the first example, the racks are addressed in one big group, and cannot subsequently be separated into clusters without wires running between the clusters.  In the second example, the racks are arranged in clusters of three before assigning the addresses, and the Rack Cluster constraint ensures no wires run between the clusters. Figure 1 – Impossible to split racks into clusters after addressing (photo: Finale 3D).     Figure 2 – Splitting the racks into clusters before addressing results in one module per cluster.  

Choosing the best sort order for the addresses can affect the efficiency of setting up the show from end to end.  The rack layout, for example, depends on the addresses of effects with different angles and sizes.  If a module addresses multiple size or angle effects, that forces the crew to setup racks for each of those sizes or angles within reach of the module. Both the sort order and constraints affect how often a module serves multiple sizes or angles.  Constraints prevent a module from serving multiple sizes or angles, at the expense of unused pins.  Sort order reduces the occurrence, with fewer unused pins.  If you sort the modules by size, then only the module at the transition between one size and the next will serve multiple sizes.  Same for angles.  If there are many modules at the position, then these few transition modules may be acceptable. Table 1 – A good choice for sort order and constraints for many types of shows Addresses sorted by Position > Size > Angle Modules constrained to same Position, Size   The table above shows a good choice for the sort order and constraints for a wide range of shows.  Another option is to constrain modules by Position, Size, and Angle-Plus-Minus, where Angle-Plus-Minus means that modules can serve left-leaning, straight up, or right-leaning angles, without regard to the specific number of degrees, but cannot serve any combination of angles that lean different directions.    Adding the Angle-Plus-Minus constraint causes additional pins to go unused at the transitions between the three groups of angles, but not nearly as many pins as if you add Angle to the constraints. If Angle-Plus-Minus isn’t exactly what you want to use as a constraint, you can also make your own field in the Custom Script Field, and use that as a constraint.  As an example, you could make your own version of the Angle-Plus-Minus field by sorting the script by angle and filling in the values L and R in the Custom Script Field for the left-leaning and right-leaning effects (using the letters L and R is an example; you could use any notation you want).  Having added those field values to the Custom Script Field, you would address the show with the sort and constraints of: Table 2 – A choice for sort order and constraints that allows splitting apart angled rack groups Addresses sorted by Position > Size > Angle Modules constrained to same Position, Size, Custom Field   The Custom Position Field is another field that you can use for addressing sorts and constraints.  As you can guess from the name, this field is a property of the positions.  Each script row inherits the Custom Position Field from the position at which the script row is located.  If you want to sort or constrain addresses based on a property of the positions, you can set the Custom Position Field values on the positions themselves, rather than setting the Custom Script Field for each script row individually.  As a simple example, imagine that your positions were named A, B, and C, and for some reason you wanted addresses to be assigned by order of positions but in the order B, A, C.  You could set the Custom Position Field values for A, B, and C, to 2, 1, 3, respectively, and then assign addresses sorted by the Custom Position Field.