To create and export a script for the MainFX firing system, please follow these three steps: Design the show. Address the show ("Addressing > Address show"). Export the script ("File > Export > Export firing scripts"). Step 3 creates the script file, which is a JSON file that you can import into your firing system.   Figure 1 – The MainFX firing system   The MainFX script is a JSON text file that supports 30, 100, and 10k pin modules.    Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line JSON .out UTF-8 Not applicable Not applicable   The script is a JSON array of objects ("rows") for firing events, i.e., unique combinations of module, pin, and ignition-time.  Multiple effects can be combined on a single cue. The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Sort order of rows Rows sorted ascending first by event time. What rows represent Rows represent firing events, i.e., unique module-pin-ignition-time events.  If multiple effects are triggered on the same cue, the effects are combined in name field, but the row is still just one row. Supported modules S-BOX 30, S-BOX 100, and Custom 10K modules are supported, with 30, 100, and 10k pins respectively. Minimum separation between cues 10ms   The JSON objects include the necessary information for each ignition event, consisting of some values derived from the show data in Finale 3D and other values with hard coded, constant values.    Table 3 – Specifications of script fields Field name Description action (int) The value 1 between (int) Time in milliseconds between the previous row's event time and this row's event time, or zero for the first row ch (int) Pin number delay (int) Event time in milliseconds with 10ms resolution (last digit is always zero) freeze (bool) The value false id (int) The row number, beginning with 0 position (int) The module number, beginning with 1 (not the "launch position" in Finale 3D, which is not represented in the MainFX script) time (int) The value 100 type (int) The value 2 name (string) The effect name, or effect names if the row represents multiple rows with different names size (string) The size of the first effect quantity (int) The number of devices represented by the row angle (string) ASCII graphics angle representation of all effects represented by the row, preceded by a list of angles followed by a dot character if any angles are non-zero The example script below is from a show with nine positions, illustrating rows with various combinations of effects.  The first eleven rows each have a single effect.  The next three rows have 2, 2, and 3 effects respectively.  The first of those three has two effects of different names, which are combined in the name property separated by comma.  The remaining rows have homogeneous effects, so their name properties consist of a single name.   [{"action":1,"between":0,"ch":1,"delay":2760,"freeze":false,"id":0,"position":1,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":1,"delay":3260,"freeze":false,"id":1,"position":2,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":1,"delay":3760,"freeze":false,"id":2,"position":3,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":2,"delay":4260,"freeze":false,"id":3,"position":4,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":2,"delay":4760,"freeze":false,"id":4,"position":5,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":2,"delay":5260,"freeze":false,"id":5,"position":6,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":1,"delay":5760,"freeze":false,"id":6,"position":7,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":1,"delay":6260,"freeze":false,"id":7,"position":8,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":500,"ch":1,"delay":6760,"freeze":false,"id":8,"position":9,"time":100,"type":2,"name":"Red Chrysanthemum","size":"50mm","quantity":1,"angle":"|"}, {"action":1,"between":2220,"ch":1,"delay":8980,"freeze":false,"id":9,"position":4,"time":100,"type":2,"name":"Indigo Chrysanthemum","size":"3"","quantity":1,"angle":"|"}, {"action":1,"between":0,"ch":1,"delay":8980,"freeze":false,"id":10,"position":6,"time":100,"type":2,"name":"Indigo Chrysanthemum","size":"3"","quantity":1,"angle":"|"}, {"action":1,"between":3000,"ch":1,"delay":11980,"freeze":false,"id":11,"position":5,"time":100,"type":2,"name":"Indigo Chrysanthemum, Yellow Chrysanthemum","size":"3"","quantity":2,"angle":"-45 +45. \/"}, {"action":1,"between":6000,"ch":3,"delay":17980,"freeze":false,"id":12,"position":6,"time":100,"type":2,"name":"Yellow Chrysanthemum","size":"3"","quantity":2,"angle":"-45 +45. \/"}, {"action":1,"between":9000,"ch":2,"delay":26980,"freeze":false,"id":13,"position":7,"time":100,"type":2,"name":"Yellow Chrysanthemum","size":"3"","quantity":3,"angle":"|||"}] Figure 2 – Example MainFX script

To create and export a script for the IGNITE firing system, please follow these steps: Design the show. Address the show ("Addressing > Address show"). Export the script ("File > Export > Export firing scripts").  This function creates an Excel XLSX file containing the rows, and it also copies the rows into the system clipboard so you can paste them into a text editor or the IGNITE designer web application. Paste the script rows into designer.ignitefiringsystems.com.  Select the first row in the table on this web page, then press Ctrl+V.   Figure 1 – The IGNITE firing system module   The exported IGNITE script is a list of rows represented as text with tab separated fields.  The method of transferring a show designed in Finale 3D to the IGNITE system is to address and export the show from Finale 3D and then paste (or copy/paste from exported XLSX file) the rows into a blank show in the IGNITE designer web application. The "Event Time" field in IGNITE corresponds to the "Effect Time" in Finale 3D, i.e., the break of a shell as opposed to the launch of a shell.  The "Color" and "Cue" fields in IGNITE correspond to the "Rail" and "Pin" columns in Finale 3D.   The six colors in IGNITE, beginning with red, are rail numbers 0-5 in Finale 3D.  The pin and cue numbers, and the "Firework Name" and "Duration" fields have the same meaning in IGNITE and Finale 3D.  The "Igniter Pre-fire" field in IGNITE corresponds to the "Prefire" field in Finale 3D.   Table 1 – Clipboard format and encoding Clipboard format Extension Text encoding Field delimiter End-of-line Text XLSX UTF-8 Tab CRLF The script contains rows for the firing events, i.e., unique combinations of module, channel, and ignition-time.  Multiple effects can be combined on a single cue. The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Sort order of rows Rows sorted ascending first by Event Time. What rows represent Rows represent firing events, i.e., unique module-channel-ignition-time events.  If multiple effects are triggered on the same cue, the effects are combined in name field, but the row is still just one row. Special characters The script may contain any Unicode characters except the comma character and control characters like tab or carriage return.  Finale 3D automatically strips out the comma characters from exported scripts. The IGNITE script has no header, just a list of rows corresponding to the firing events.  Each row has six fields, defined as follows:   Table 3 – Specifications of script fields Field name Description Event Time The Effect Time (the break time, not the launch time) in the format MM:SS.D from the beginning of the show (1/10th second resolution) Color Module number, from 0-5 Cue Pin number, from 1-18 or 1-36 Firework Name The effect description (up to 62 Unicode characters, including double quote and characters from other languages but not comma) Duration Duration in seconds without fractional seconds (integer) Igniter Pre-fire Prefire as a floating point number with 1/10th second resolution The example script below has three cakes, all shot from the same module (0, or red).  The first two cakes are long, at 22 and 18 seconds respectively.  The third cake is an all-at-once shell cake, and therefore has an Igniter Pre-fire equal to the lift time, represented in the Igniter Pre-fire field even though the delay is in the aerial delay fuse, not the igniter.   00:05.0 0 3 Slingin' Rhymes 22 0.0 00:30.7 0 1 Green Ice 18 0.0 00:53.7 0 2 Say Again? 1 1.7 Figure 2 – Example IGNITE script as text   Figure 3 – Example IGNITE script as shown in the IGNITE designer web application

The "Addressing algorithm" is the procedure the computer follows to assign modules, pins, racks and tubes to the events of the show.  The basic procedure is a lot like what a human would do: Decide in what sort order you will assign addresses to effects. Take the first effect in that order, and assign it the lowest number module, pin, rack, and tube that satisfy all the constraints. After the assignment, look ahead to assign any same-time or same-chain effects to the same module and pin and the lowest number rack and tube that satisfy constraints. Repeat from step (2) until finished. Rearrange the tubes in the single-shot racks to avoid collisions between tubes with crossing angles. If you turn off step (5) rearrangement, the results of the algorithm are fully transparent and 100% determined by the sort order and the constraints specified in the addressing dialog, meaning that a human could follow these same steps to get the same result.  You can fall back on this truth if you ever question the results of the addressing algorithm: follow the same steps and see if you get the same result.   Sort order The sort order is a list of criteria, sorting first by criterion 1, then breaking ties by criterion 2, then breaking further ties by criterion 3, etc.  Sort criteria include attributes like Position Name, Size, and Part Number.  In fact it is easy to imagine assigning modules and pins sorted by those exact criteria, and many people do. Sort criteria can also include conditional terms, like "Size >= 50mm (If Single-Shot)", which sorts single-shot items of size >= 50mm first; then other single-shot items; then non-single-shot items in their original order.  The purpose of conditional sort terms with phrases like "(If Single-Shot)" is to apply some criteria to some kinds of effects without affecting others.  For example, it may be important to assign racks and tubes to large (>= 50mm) single-shots before others if a launch position has a limited number of racks capable of holding the larger effects, which you wouldn't want to fill with smaller effects until ensuring you have dealt with all the large effects. Sort criteria can also include derived terms like "Rack Number", which prioritize effects that fit in the next rack according to the Rack Numbers.  The precise definitions and calculations of derived terms like Rack Number are often complicated.  If the meaning isn't obvious or if you are trying to step through exactly what the computer is doing, you can refer to the list of terms and their definitions here: Special sort terms.   Constraints Unlike the list of sort order terms, constraints come from multiple places.  The addressing dialog provides lists of constraint fields applying to modules, slats, pins, and racks, and provides the constraint, "Max. e-matches per pin".  The rack definition dialog for the "Create/edit rack" functions includes pre-wired pins, various size constraints, usable length of rack row constraints for Pyrolamas-like racks, and constraints related to angles.  Effects have a Type property that must be compatible with the rack structure (cake racks vs. single-shot racks, etc.).  Positions can have pre-wired rails.  Script rows can have Rack Type values that are required to match the Rack Type properties of the racks. Like sort terms, constraint fields applying to modules, slats, pins, and racks can refer to attributes like Position, Size and Part Number, or other more complicated conditional and derived terms like "Rack (If Single-Shot)" or "Chain-Or-Not" (see Special constraints). The important characteristic of constraints is that they combine in a principled manner.  The combination of constraint 1 and constraint 2 means simply that constraint 1 and constraint 2 must both be satisfied by any assignment of modules, pins, racks, and tubes.  Because of this characteristic, you can configure the addressing algorithm to take into account a staggeringly large and complex set of considerations while still being able to rely on the predictability and verifiability of the result.   Example sort order and constraints for single-shot racks with pre-wired pins Addressing for pre-wired pins on racks with angle range constraints requires a significant amount of sort order and constraint calculation which illustrates the complexity.   The specific terms are listed in Table 1 of Racks with pre-wired pins.  Figure 1 is an excerpt:   Figure 1 – Example sort order and constraints for pre-wired pins.   The "Tilt > 50° — Single-Shot" sort term guarantees that single-shots angled more than 50° get to allocate the tube holders on the ends of the rows that are the only holders capable of rotating to those extreme angles.  Similarly, the "Size >= 50mm -- Single-Shot" sort term ensures large holder single-shot racks are allocated first to the large effects that need them.  The "One Single-Shot Rack" constraint restricts a module to zero or one single-shot rack but allows pins to be shared with other non-single-shot racks.  See Racks with pre-wired pins for the full explanation of the terms in this example.  

To create a rack with multiple rows of tubes or tube holders, and to have that rack appear in rack layout diagrams with the pin number text oriented upright, it is necessary to understand Finale 3D's definition of "row" and "standard orientation". The meaning of "row" in rack definitions in Finale 3D is a line of tubes that either tilt together or fan out along the line.  This meaning makes sense for wooden racks for shells, because everyone would agree that the rack in Figure 1 is one row of tubes. Figure 1 –The meaning of "row" in rack definitions is a line of tubes that either tilt together or fan out along the line.   For racks with multiple rows, row #1 is on the left in the orientation of the rack definition, which would point toward the audience or down in the rack layout view if the rack is not rotated.  Imagine if the rack of Figure 1 had four rows, side by side, and the tubes could fan out within the rows, i.e., a Fan row rack.  It would look a lot like the rack in Figure 2.   Figure 2 –In fan row racks, the rows are perpendicular to the pivot rods that the holders rotate around.   In fan row racks, the rows are perpendicular to the pivot rods that the holders rotate around.  It is easy to tell how many rows a fan row rack has by just by looking at the knobs on the ends of the rods.  Count the number of tube holders that rotate around a rod.  That's the number of rows!  Fan row racks are usually rotated 90° counter-clockwise to make the rows aim sideways for tubes within them to make left/right fans from the audience perspective.   Figure 3 –In tiltable row racks, the rows are the tracks that the tubes slide onto.   In a Tiltable Row Rack like in Figure 3, the rows are the tracks that the tubes slide onto.  To tell how many rows a tiltable row rack has, just count the tracks.  Tiltable row racks are usually not rotated in the rack layout because the rows aim forward and tilt sideways to make left/right fans from the audience perspective.   A trick to remember A trick to remember the row orientation in the rack definitions versus when rotated in the rack layout view is: Hold your left arm out in front of you, wrist bent, fingers together pointing down.  Your fingers are the rows, pinky finger being row #1.  The tube numbers counting “By rows, left to right” start with the first pin at the base of the pinky finger, progressing down to the finger tip, then continuing at the base of the ring finger.  If the rack is rotated 90° counter-clockwise to make the rows horizontal from the audience perspective, that’s like rotating your hand 90° counter-clockwise.  In that orientation the first row represented by your pinky finger is closest to the ground, which is equivalent to closest to the audience in the rack layout view. Finale 3D includes options to count tubes in other orders like "By rows, right to left" and "Across rows, right to left" (see Tube loading order).  You can use the hand/finger trick to visualize the tube numbers in the rack definition versus rotated in the rack layout.  The order definitions are interpreted in the orientation of the rack definition (left hand fingers pointing down).  Thus the order "By rows, right to left" begins with pin 1 at the base of the index finger, progressing to the finger tip.  If the rack is rotated 90° counter-clockwise in the rack layout, pin 1 would be in the back left, and pins 2, 3, 4, ... would progress to the right.   Standard orientation In shows, fan row racks are usually oriented with the fan angles going from side to side. Finale 3D offers the choice in the "Create rack" dialog to change the standard orientation of the rack to be rotated 90° counter-clockwise to make rows sideways to the audience by default.  Changing the standard orientation doesn't change the meaning of rows in the rack definition.  It just changes the default orientation that the rack will appear in when added to the show, and it changes the orientation of the pin number text and other text to be upright when the rack is in its standard orientation.   Figure 4 –The standard orientation dictates the orientation of the pin number text and other text.   When adding racks to the rack layout of a show, the racks must be in the correct orientation to accommodate the effect angles.  If the effects are angled left and right, the rack's rows need to be aiming left/right.  It is hard to tell from looking at a single-shot rack's tube circles in the rack layout view which direction the rows are aiming since the rows could run in either direction, so Finale 3D draws the rod end knobs on the sides of the rack, indicating the direction of the rods.  It is easy to imagine the tubes rotating around the rods, which tells you whether the rows are aiming in the right direction.   Figure 5 –The little knobs on the sides of the rack are the ends of the rods that the tube holders rotate around.  

The Spark Fabrica SF-X2 Spark Spin fixture is a sparks fixture with two nozzles on a rotating platform that can be controlled by any of the DMX-capable firing systems, such as Piroshow, Pyromac, PyroSure, fireTEK, Cobra, Fire Control G2, and Mongoose.   Figure 1 – Spark Fabrica SF-X2 Spark Spin   Capabilities The Spark Spin fixture has two channel configuration options, with 2 and 4 channels.  Finale 3D only supports the 4 channel option.  The four channel option provides independent control over the two spark nozzles and over the spinning platform.   Table 1 – DMX channel configuration options DMX Channel Mode Supported in Finale 3D 2CH NO 4CH YES   Adding spark effects and controlling the spinning platform To add a sparks effect to your show, simply insert one of the sparks effects from the supplier catalog, such as "SF-X8 [202/0417] One Sec Sparks (md)".  Since the two nozzles are typically used together, the effects in the supplier catalog trigger both nozzles together. To make the platform spin, insert the "SF-X2 [201/0537] With Clockwise Spinning" effect, or the counter-clockwise option, and extend its duration on the timeline to cover the period over which the platform is spinning.  The spinning of the platform and the triggering of the nozzles are independent actions. The animation capabilities in Finale 3D are not currently capable of animating the effects for this fixture in a manner that remains consistent if you change the duration of the effect, and in a manner that is determined by the combination of the spinning effects and the triggering effects.  Thus, as of June 2024 the animations of the non-macro effects for this fixture are simply a single spark jet that does not spin. Finale 3D provides some macro effects, however, that include animation of the two nozzles and the spinning together.  The macros have pre-defined, non-adjustable duration, and the macros combine the spinning and the triggering together, thereby working around the animation limitations.  If the macro options have duration and spinning characteristics that are acceptable for your show design, use them instead of the non-macro effects to take advantage of their animation.  The macros produce the same DMX firing system script export data; the only difference is the macro effects have predefined durations. If none of the provided macros have the duration or spinning speed that you are looking for, you can create your own macros using the Effect macros features, by combining the non-macro effects for your desired duration and by adding spinning animation in the Effect Data field of the events.   Table 2 – DMX channels DMX Channel Meaning Channel 1 (DMX Channel Base + 0) Nozzle 1 height (0 - 15 = off, 16  -90 = low height; 91 - 170 = medium height; 171 - 255 = high height) Channel 2 (DMX Channel Base + 2) Pre-heat (0 - 239 = OFF: 240 - 255 = ON) Channel 3 (DMX Channel Base + 4) Nozzle 2 height (0-15 = off, 16-90 = low height; 91-170 = medium height; 171-255 = high height) Channel 4 (DMX Channel Base + 5)  Spin rate (0 - 15 = OFF; 16 - 135 = clockwise spinning; 136 - 255 = counter-clockwise spinning)   Instructions To design a show for Spark Fabrica SF-X2 Spark Spin units, please follow these steps:  Set up.  (A) Follow the set up instructions in DMX basic instructions.  Depending on your DMX controller, you may choose to give each each fixture its own DMX universe, or give each fixture a channel range in a shared DMX universe.  (B) In the real world configure each physical fixture unit's "Start Address" to be the start of the channel range you allocate for it. (C) In Finale 3D configure the "DMX Channel Base" of the fixture to match the Start Address exactly. Add the Spark Fabrica supplier catalog to your Finale 3D account.  Login to the finale3d.com website.  At the top of the page, go to “My Account > Supplier Catalog Settings” (www.finale3d.com/supplier-catalogs-settings/).  Find the Spark Fabrica supplier catalog in the table, and turn the switch to ON.  Then launch the Finale 3D application and synch to network.  The Spark Fabrica catalog will appear as one of the available collections in the effects window, which you can choose from the selector at the top of the window.  This catalog contains effects for all types of Spark Fabrica fixtures currently supported in Finale 3D, together. Add effects to the show.  In the 3D view, click on a Spark Spin position to filter the effects window to compatible effects.   Choosing the DMX channel ranges for fixtures Each Spark Spin fixture requires multiple channels, so if you are putting multiple fixtures in the same DMX Universe, you need to set the Start Address on the fixture in the real world and the corresponding DMX Channel Base on the fixture in Finale 3D to a range of channels that doesn't overlap with others.  A DMX universe has channels 1-512.  If you want to pack as many fixtures into the 512 channels of a DMX universe as you can, back-to-back ranges are the most efficient.  Table 3 shows an example for Spark Spin fixtures.  Some DMX firing systems only support 50 or 100 channels, so you may not have all 512 channels to work with.   Table 3 – Example channel ranges for 4CH Spark Spin fixtures Fixture DMX Channel Base Channels Used 1 1 1-4 2 5 5-8 3 9 9-12 4 13 13-16 5 17 17-20 ... 85 509 509-512     Table 4 – Example files and downloads Download link Explanation SF-X2 SPARK SPIN USER MANUAL.pdf Spark Fabrica SF-X2 Spark Spin  user manual

The Spark Fabrica SF-Z5 Fly Spark fixture is a moving head sparks fixture that can be controlled by any of the DMX-capable firing systems, such as Piroshow, Pyromac, PyroSure, fireTEK, Cobra, Fire Control G2, and Mongoose.   Figure 1 – Spark Fabrica SF-Z5 Fly Spark   Capabilities The Fly Spark fixture supports direct control of the head angle over DMX, and it also supports a set of 72 pre-defined firing pattern macros.  Finale 3D only supports the direct control of the head angle features.  As of June 2024, Finale 3D does not support the 72 pre-defined firing pattern macros.   Specifying the angle of effects To add a sparks effect to your show at a specific angle, simply insert one of the sparks effects from the supplier catalog, such as "SF-Z5 [200/0417] One Sec Sparks (md)".  Then adjust the duration on the timeline to the desired duration by dragging the right end of the effect bar in the timeline, and adjust the angle by dragging the control point at the top of the effect's trajectory in the 3D view. To animate the moving head angle, insert a Move-In-Black effect to specify the starting angle of a movement; and then add a Move-To While On effect shortly after the Move-In-Black effect to specify the ending angle of the movement.  Adjust the trajectory angles of the Move-In-Black effect and the Move-To While On effects to specify the angles.  The time between the two events is the duration of the sweep.  You can add additional Move-To While On effects after the first in a sequence, each with its own angle, to create a back and forth sweeping animation. As of June 2024, the majority of firing systems do not have support for ramping a DMX channel value, and Finale 3D's firing system exporter does not yet support ramps, so as of this date the angle sweeps created with Move-In-Black and Move-To While On effects for this fixture will move at the fixture's maximum speed, regardless of the duration between the Move-In-Black and Move-To While On effects.  It is not possible at this time to design a slow moving angle sweep for this fixture in Finale 3D. The situation with ramps is changing this year (2024).  Most of the major firing systems are nearing completion of their support for ramps.  Concurrently, Finale is in the process of improving its DMX exporter to use the new ramp features of the firing systems to control the speed of animated parameters like the angle sweeps for this fixture. Finale's improved exporter will also provide a similar control of angle sweep speed for firing systems that do not have ramp capabilities by automatically using multiple events in a stair step sequence to change the angle parameter.  Finale's exporter will provide the user with options to manage this capability since it enlarges the script size with the multiple event sequences.   Table 1 – DMX channels DMX Channel Meaning Channel 1 (DMX Channel Base + 0) Angle from 90° to -90°，128 or 0 and 1upwords (128 is up, 255 is to the right; values down to 3 are to the left; as a special case, values 0 and 1 are also up) Channel 2 (DMX Channel Base + 1) Unused, write 0. Channel 3 (DMX Channel Base + 2)  Height (0-15 = off, 16-90 = low height; 91-170 = medium height; 171-255 = high height) Channel 4 (DMX Channel Base + 3) Unused, write 0. Channel 5 (DMX Channel Base + 4) Sequence (0 - 2 or 186 - 255 = no sequence; 3 - 185 = sequence based on the formula: channel value = 2 + sequence number * 2.55, rounded to nearest)   Channel 6 (DMX Channel Base + 5)  Pre-heat (0 - 49 or 201 - 255 = OFF: 50 - 200 = ON)   Instructions To design a show for Spark Fabrica SF-Z5 Fly Spark units, please follow these steps:  Set up.  (A) Follow the set up instructions in DMX basic instructions.  Depending on your DMX controller, you may choose to give each each fixture its own DMX universe, or give each fixture a channel range in a shared DMX universe.  (B) In the real world configure each physical fixture unit's "Start Address" to be the start of the channel range you allocate for it. (C) In Finale 3D configure the "DMX Channel Base" of the fixture to match the Start Address exactly. Add the Spark Fabrica supplier catalog to your Finale 3D account.  Login to the finale3d.com website.  At the top of the page, go to “My Account > Supplier Catalog Settings” (www.finale3d.com/supplier-catalogs-settings/).  Find the Spark Fabrica supplier catalog in the table, and turn the switch to ON.  Then launch the Finale 3D application and synch to network.  The Spark Fabrica catalog will appear as one of the available collections in the effects window, which you can choose from the selector at the top of the window.  This catalog contains effects for all types of Spark Fabrica fixtures currently supported in Finale 3D, together. Add effects to the show.  In the 3D view, click on a Fly Spark position to filter the effects window to compatible effects.   Choosing the DMX channel ranges for fixtures Each Fly Spark fixture requires multiple channels, so if you are putting multiple fixtures in the same DMX Universe, you need to set the Start Address on the fixture in the real world and the corresponding DMX Channel Base on the fixture in Finale 3D to a range of channels that doesn't overlap with others.  A DMX universe has channels 1-512.  If you want to pack as many fixtures into the 512 channels of a DMX universe as you can, back-to-back ranges are the most efficient.  Table 2 shows an example for Fly Spark fixtures.  Some DMX firing systems only support 50 or 100 channels, so you may not have all 512 channels to work with.   Table 2 – Example channel ranges for 6CH Fly Spark fixtures Fixture DMX Channel Base Channels Used 1 1 1-6 2 7 7-12 3 13 13-18 4 19 19-24 5 25 25-30 6 31 31-36 7 37 37-42 8 43 43-48 9 49 49-54 10 55 55-60 ... 85 505 505-511     Table 3 – Example files and downloads Download link Explanation SF-Z5 FLYSPARK USER MANUAL.pdf Spark Fabrica SF-Z5 Fly Spark user manual

For various purposes you may find yourself needing to add effects to a show design strictly for the visualization, effects that you don't want to be part of the exported firing system script or to consume racks.  Although various workarounds exist, the <Exclude This Position> choice in the firing system selector of position properties is the feature meant for this purpose.   Figure 1 – The Firing System field of the Edit Properties dialog has an <Exclude This Position> option.   Figure 1 shows the selected option.   After setting this option for a position, the "Addressing > Address show..." function and other addressing functions will fill the Universe, Section, Module Or Slat Type, Rail, Pin, Rack, and Tube fields of all events at the position with blank values.  The "Racks > Add racks for show..." and other racking functions will not add racks for the position.  The rack layout view will not show the list of red circles representing unaddressed shells.  The export firing system script functions will ignore events at the position if their Rail and Pin properties are blank (which they will be as a result of addressing the show).      

SMPTE 29.97 NDF progresses through HH, MM, and SS slower than the progression of time in the real world (called "wall clock" time) by 1.2 seconds for every 20 minutes.   It advances the HH, MM, and SS by one second after the passage of every 30 frames, but the frames are playing back at only 29.97 per second, so the HH, MM, SS advance at a rate of 29.97 / 30 as fast as wall clock time. If the script event times are in wall clock time, the slower rate playback causes the script playback to become out of synch with the music, running slower than the music by 1.2 seconds per 20 minutes.  To compensate, the event times in the script need to be based on 29.97 NDF time rather than wall clock time.  An event at the end of a script that is exactly 20 minutes long in wall clock time should have an event time of 00:19:58:24 in the script. Some controllers have an option to compensate for the slower-than-wall-clock rate of SMPTE 29.97 NDF.  Notwithstanding, if the show contains multiple timecode sections, the reason to not configure the controller to compensate for the slower-than-wall-clock rate of SMPTE 29.97 NDF is that each individual timecode section is expected to start at a specific, agreed upon SMPTE frame, such as beginning on SMPTE 01:00:00:00, 02:00:00:00, etc.  An event at the start of timecode section 01:00:00:00 is expected to trigger on the literal SMPTE frame 01:00:00:00, not "the SMPTE frame that corresponds to 1 hour wall clock time in whatever the SMPTE frame rate is". When adding a soundtrack to your show, if you elect for Finale 3D to split the soundtrack's timecode sections apart and automatically position them independently on the timeline, Finale 3D will position them on the timeline at the wall clock time interpretation of the SMPTE HHMMSSFF timestamps, even if the SMPTE timecode sections internally are in SMPTE 29.97 NDF.  Similarly, if you slave the playhead in Finale 3D to external timecode input (see Timecode basic instructions), the playhead will be positioned according to the wall clock time interpretation of the timestamps.   Adjusting times in the script for SMPTE 29.97 NDF timecode When Finale 3D exports a firing system script, it provides an option: "Adjust times for SMPTE 29.97 NDF timecode" with the options shown in Figure 1.   Figure 1 – The options for "Adjust times for SMPTE 29.97 NDF timecode"    The YES options all adjust the times in the script to compensate for the expected slower-than-wall-clock progression of the controller.  Obviously, if you use these options then you should not also configure the controller to compensate for the slower-than-wall-clock rate, because doing so would doubly compensate.   Table 1 – SMPTE 29.97 NDF adjustment options in Finale 3D Adjustment When to use it Imported songs must include SMPTE timecode Yes, relative to 00:00:00:00 on timeline You should use this setting if your controller will be receiving SMPTE 29.97 NDF timecode from an external source, and if the show begins at approximately zero on the timeline in Finale 3D. Finale 3D expects the controller's clock to advance more slowly than real time when receiving SMPTE 29.97 NDF timecode. With this setting, Finale 3D adjusts the script times to compensate for the slow clock advancement and keep the script in synch with the music. No, doesn't matter Yes, relative to the first event You should use this setting if your controller will be receiving SMPTE 29.97 NDF timecode from an external source, and if the show begins at a large offset on the timeline in Finale 3D (like 01:00:00:00). Finale 3D expects the controller's clock to advance more slowly than real time when receiving SMPTE 29.97 NDF timecode. With this setting, Finale 3D adjusts the script times to compensate for the slow clock advancement and keep the script in synch with the music. No, doesn't matter Yes, for each 29.97 NDF timecode section You should use this setting if the show contains separate timecode sections for the songs, and if some or all of the sections use SMPTE 29.97 NDF timecode. Finale 3D expects the controller's clock to advance more slowly than real time when receiving SMPTE 29.97 NDF timecode. With this setting, Finale 3D adjusts the script times in each SMPTE 29.97 NDF timecode section relative to the start of the section to compensate for the expected slow clock advancement and keep the script in synch with the music.  The time adjustments are only applied to SMPTE 29.97 NDF timecode sections. Yes   The first two YES options convert all the event times of the show to compensate for slower-than-wall-clock progression of the controller.  The difference is whether the adjustments are relative to zero on the timeline or relative to the first event.  Concerts with shows or songs that execute at agreed upon SMPTE times often require large offsets, like beginning at 01:00:00:00 or even 23:00:00:00.  At show time, when the SMPTE at 01:00:00:00 or 23:00:00:00 starts playing, that's the cue for the show to start.  If the SMPTE is 29.97 NDF, then it will be progressing in HH, MM, SS, FF slower-than-wall-clock from that point forward.  Thus the needed time adjustment is relative to the start time, 01:00:00:00 or 23:00:00:00, not relative to zero. So, if the show begins at a SMPTE offset on the timeline in Finale 3D, use the second YES option to make adjustments relative to the first event.  If the show begins at SMPTE zero, or if you are using a firing system export offset in Finale 3D for the SMPTE offset, then you can use the first YES option.  In those cases there usually isn't much difference between the first and second YES option anyway since the first event is usually near zero, so as a rule of thumb if the show does not have multiple timecode sections, you can always use the second YES option. The first two YES options do not require that Finale 3D knows about your timecode.  These options are available even if you import a soundtrack or song into Finale 3D as audio-only, without timecode. The third YES option only converts the events in SMPTE 29.97 NDF timecode sections, leaving other timecode sections alone.  Thus the third YES option does require that you import your soundtrack or individual songs along with their timecode, so Finale 3D can know which events to convert and what the start time the conversion is relative to.

The addressing functions divide up positions into addressing groups of positions that can share modules and that do not have different Pre-Assigned Rails.  The addressing functions then assign addresses to the addressing groups one after another.  Within an addressing group, positions can share modules.  Between addressing groups, positions cannot share modules unless their Pre-Assigned Rails overlap. Typically positions do not share modules and thus typically addressing groups are indistinguishable from positions themselves, but if the addressing dialog or addressing blueprints do not include the constraint that restricts modules to a single position, then an addressing group may contain more than one position. If positions do not share modules, then further details about addressing groups have no bearing on the assigned addresses.  If positions do share modules, the following sections explain the implications for sorting of addresses and sharing of modules.   Criteria for sharing modules If the addressing dialog or addressing blueprints have the constraint that restricts modules to a single position, then positions cannot share modules.   Without that constraint, positions might be able to share modules but only if the positions also have the same: Firing System Controller Module Type Universe Addressing Blueprint Start Module Section Positions with different Firing System Controller or Module Type or Universe properties can't share modules because addresses can't be part of two things at once.  Similarly, positions with different Addressing Blueprint or Start Module also can't share modules because these fields affect the rules for assigning addresses, and a position couldn't be subject to two different sets of addressing rules at the same time.  Section is a property that is specifically designated as needing to be the same among positions sharing modules.  If two positions differ in any of these six properties, or if they have different Pre-Assigned Rails, they cannot be in the same addressing group.   Addressing groups affecting the sort order of positions The addressing dialog and the addressing blueprints enable you to specify the sort order in which addresses are assigned.   The most common sort criterion is sorting alphabetically by Position Name.   Although people generally think of sort criteria as applying globally across the whole show, the sort criteria actually apply within each addressing group.  If you think about it, it couldn't be any other way, because different addressing groups can have different blueprints that specify different sort criteria. Consider a set of six positions, A, B, C, D, E, F, addressed without the constraint restricting modules to a single position.  Positions A, C, and E are sharing modules in one addressing group (say they have Section = "rooftop"); the other three positions are sharing modules in a different addressing group (say they have Section = "road", causing them to be a different group).  Because the sections are different, there is no sharing of modules between A, C, E and B, D, F. If you address the whole show sorting by Position Name, you are probably surprised to see the addresses assigned to positions in the order A, C, E, B, D, F.  The reason is, the addressing function assigns addresses for the first group containing positions A, C, E in order; and then it assigns addresses for the second group containing positions B, D, F in order. If the sort criteria apply within each addressing group, what sort criteria apply between addressing groups?  In the example above the addressing function assigns addresses for the A, C, E group as the first group, but how did it decide that was the first group?  More generally, how are the addressing groups sorted relative to each other? Addressing groups are sorted relative to each other based on the "sort factor" of each group.  Depending on the sort criteria from the addressing dialog or applicable blueprint, each group's sort factor is either the alphabetically first Position Name in the group, or the alphabetically first Custom Position Field in the group, with the Position Name as the tie breaker.  In the example above, the sort factor for group A, C, E is "A"; the sort factor for group B, D, F is "B"; so group A, C, E is first. If the sort criteria from the addressing dialog or blueprint do not explicitly begin with Position Name or Custom Position Field, the sort factor is Position Name by default.  If different addressing groups have different sort factors based on different sort criteria (Position Name versus Custom Position Field), then the apples to oranges comparison between the groups is undefined but deterministic.  If multiple addressing groups have the same non-blank Start Module, then as a special case the addressing algorithm adjusts the sort order to make those specific addressing groups consecutive, as described in the Start Module paragraph below.   Section Unless the Pre-Assigned Rails cause addressing groups to use the same modules, the firing system addresses assigned in one group will never be shared with positions in a different addressing group.  That's what makes the Section field a useful feature.  By assigning different Sections to positions, you can force those positions or groups of positions to not share modules or pins that they otherwise would share (see Using the Section field in position properties).   Start Module The addressing algorithm assigns addresses for the groups one after another, starting each group with the next module number after the largest module number assigned in the previous group (excluding Pre-Assigned Rails groups) and adjusting the "next available rail" by the Start Module and Pre-Assigned Rails for the group.  If you assign Start Module 50 to an addressing group in the middle of the sort order and if it uses one module, the subsequent addressing groups will continue allocating modules from 51 onward. If you assign different Start Modules to positions, you need to ensure the gaps between the Start Modules are large enough to avoid overlapping ranges.  Consider a set of positions in two addressing groups X and Y.  For simplicity, you could just think of each addressing group as a single position, X and Y.  If addressing group X begins with Start Module 10 and requires five modules (10, 11, 12, 13, 14), and addressing group Y begins with Start Module 12 and requires one module (12), the two ranges are overlapping.  That would result in an addressing error -- a collision! What do you think will happen if you assign the same Start Module to positions in different addressing groups?  It seems like you would be setting up the addressing groups for a certain collision, but since it is often useful to specify a shared Start Module for a collection of addressing groups (or even all addressing groups to make module numbers count from an arbitrary starting point globally), the Start Module works as follows as a special case: if multiple addressing groups have the same non-blank Start Module, they will allocate modules back to back, beginning with the Start Module itself for the first addressing group and not sharing modules between addressing groups.  If the first addressing group with Start Module 10 uses modules 10, 11, and 12, then the second addressing group with the same Start Module 10 will begin with module 13.  To facilitate this special case, the addressing algorithm promotes addressing groups in the sort order if necessary to make addressing groups with the same non-blank Start Module (and the same Firing System Controller and Universe) consecutive.   Pre-Assigned Rails Unlike Start Module, Pre-Assigned Rails does not affect the module numbers assigned to subsequent addressing groups.  If you assign Pre-Assigned Rails 50 to an addressing group in the middle of the sort order, the subsequent addressing groups will continue allocating modules from wherever the previous addressing group left off before the Pre-Assigned Rails 50 group. If you assign the same non-blank Pre-Assigned Rails to multiple positions, you must ensure the positions are in the same addressing group, which means all the position properties in the above criteria list must be the same.  The addressing algorithm guarantees no collisions within an addressing group, but not across addressing groups that have the same Pre-Assigned Rails. If you assign operlapping but not the same Pre-Assigned Rails to multiple positions, you must ensure the positions, which will necessarily be in different addressing groups, have pre-wired racks and pins that prevent the same firing system address from being assigned in the different positions, leaning on the use of pre-wired rails (Racks with pre-wired rails) and pre-wired pins (Pre-wired pin options) to ensure no firing system addresses are re-used across positions in different addressing groups. Imagine two positions X and Y that share a module and also have an unshared module.  Imagine position X uses modules 10 and 11; position Y uses modules 11 and 12.  The Pre-Assigned Rails for the positions are 10, 11 and 11, 12, respectively.  Since the Pre-Assigned Rails are different, the positions are necessarily in different addressing groups.  The question is how to avoid the positions allocating the same pins of the shared module 11. If position X has pre-wired racks for module 10 and 11, and if the rack pre-wired to module 11 has tubes pre-wired to pins 1-16 (in a 32 pin module), then position Y can avoid collisions by using racks pre-wired to module 11 and 12 with the module 11 rack pre-wired to pins 17-32.  To receive a firing system address, the events in position X or Y need rack tubes, and the only rack tubes available in X or Y require module and pin numbers that are not shared between the two positions.  

To create and export a pyro script for the Showven FXcommander firing system, please follow these steps: Address the show ("Addressing > Address show...") and select "Showven" and "PyroSlave X16" as the controller and module type. Export the script ("File > Export > Export firing scripts"). Step 2 creates the script file, which has the "CSV" extension.  The file format details are described in this section. The Showven FXcommander system also supports DMX fixtures.  Please see DMX basic instructions for general DMX scripting instructions.  If you are interested in how the script format incorporates the DMX commands along with the pyro commands, the details are presented in Table 2 and Table 3 in this section.     Figure 1 – Showven FXcommander firing system   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text .CSV ASCII Comma CRLF The script contains rows for the pyro firing events and DMX channel state vectors.  Multiple pyro effects fired at the same effect time can be combined in a single row if their effects have the same part number.  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 first by effect time, then by event time as secondary criterion. What rows represent Each row represents a one or more module/pin addresses of pyro effects with the same part number, fired at the same effect time (and therefore  the same prefire and event time); or a DMX channel/value state vector starting with channel 1, the length of the state vector covering all non-zero values. Header The first line of the file is the CSV header row, which specifies the fields of the following data rows: Device,Name,Timecode,Addr,Duration(s),Prefire(s),Position,Angle Time resolution Milliseconds. DMX support Showven FXcommander supports DMX fixtures sharing a single 512 channel DMX Universe.   The DMX related rows in the script are state vectors defining the values of all 512 channels at the time of the event, which are to be held for the duration of the event and then reset to zero if another event does not follow at exactly the time of the event plus its duration.   As an economy, the state vector can be shorter than 512 channel values, implying the remaining values are zero. Representing any change to any one or more channel values at a given time requires the state vector defining the state of all 512 channels at that time.  Thus rapidly changing channel values, such as an animation of a light color or moving head angle, require approximately 1.5KB times the sampling rate of memory for the script, e.g., 15KB/sec for 10Hz sample rate, if the 512 DMX Universe is fully allocated. Special characters Characters in the script are limited to low ASCII excluding single-quote, comma, semicolon, double-quote, tab, newline.   Each row in the script has a number of fields separated by the comma character.  The names of the fields and their descriptions are in following table.   Table 3 – Specifications of script Showven FXcommander fields Field name Description Device "Pyro" or "DMX" or "SAFETY", indicating the meaning of the row.  A Pyro row is a trigger of one or more pyro ignition pins; a DMX row is a DMX state vector consisting of a variable length array of channel values; a SAFETY row is a DMX state vector consisting of a variable length array of channel values -- 0 for non-safety channels, and the armed value for safety channels. Name For Pyro rows, the name of the triggered effect; for DMX rows, the fixture type of the first fixture involved in the change to the DMX state vector, where first means lowest DMX Channel Base address; for the SAFETY row, empty-string.  Maximum 128 characters, low ASCII excluding single-quote, comma, semicolon, double-quote, tab, newline. Timecode The effect time in the format HH:MM:SS:DDD.  The actual ignition time will precede Timecode by Prefire(s). Addr For Pyro rows, one or more three-digit hex numbers separated by semicolons, indicating module number (first two digits) and pin number (third digit); for DMX rows, a channel state vector consisting of a sequence of 1 to 512 two-digit hex numbers separated by semicolons indicating channel values of the corresponding channels (the first hex number is value of channel 1, not channel 0 which doesn't exist, second hex number is value of channel 2, etc.); for the SAFETY row, a sequence of one or more two-digit hex numbers indicating whether the corresponding channels are safety channels (by non-zero values that put the fixtures in the armed state) or non-safety channels (by zero values).  The channel values in DMX rows for channels that have non-zero values in the SAFETY row are ignored.  Channel value sequences in the DMX rows and SAFETY rows are variable length, up to 512 channels.  If they are shorter than 512 channels, they are equivalent to a full 512 channel sequence with zeros for the remaining values. Duration(s) For Pyro rows, empty-string; for DMX rows, the duration for which the state vector applies before channel values revert automatically to zero; for the SAFETY row, empty-string. Prefire(s) For Pyro rows, the delay from the ignition time and the effect time in floating point seconds (the ignition time = Timecode - Prefire(s)); for DMX rows and the SAFETY row, the value 0.0. Position For pyro, the name of the first involved launch position represented by the row, where first means lowest module/pin address; for DMX rows, the first fixture position involved in the change to the DMX state vector, where first means lowest DMX Channel Base address or fixture.; for the SAFETY row, empty string. Maximum 128 characters, low ASCII excluding single-quote, comma, semicolon, double-quote, tab, newline. Angle For Pyro rows, ASCII art (|/) representing the directions of the triggered effects if they are all the same or empty-string otherwise; for DMX rows and the SAFETY row, empty-string. The example script shown in Figure 2 is also available for download in Table 4. Device,Name,Timecode,Addr,Duration(s),Prefire(s),Position,Angle SAFETY,,,00;FF;00;FF;00;FF;00;FF;00;FF;00;FF,,0.0,, DMX,Sparks Flash,00:00:01:100,FF,3.0,0.0,sparkular-01, Pyro,Crossette Switch,00:00:03:842,010;110;210;310;410,,0.0,pyro-01,| Pyro,30mm Red Comet w/ Tail,00:00:09:890,850,,0.0,pyro-06,| DMX,Sparks Flash,00:00:10:000,FF;00;FF;00;FF,2.5,0.0,sparkular-03, Pyro,30mm Red Comet w/ Tail,00:00:10:811,860,,0.0,pyro-07,| Pyro,30mm Red Comet w/ Tail,00:00:18:395,870,,0.0,pyro-08,| Pyro,30mm Red Comet w/ Tail,00:00:19:286,880,,0.0,pyro-09,| Pyro,Crossette Switch,00:00:25:452,011;111;211;311;411,,0.0,pyro-01,| Pyro,1.1 PFT Green Comet w/ Tail,00:00:41:893,050;150;250;350;450,,1.1,pyro-10,| Pyro,Green Comet w/ Tail,00:00:42:980,051;151;251;351;451,,0.0,pyro-10,| Pyro,2.1 PFT Green Comet w/ Tail,00:00:46:698,052,,2.1,pyro-10,| DMX,Sparks Flash,00:00:48:100,00;00;00;00;00;00;FF;00;FF;00;FF,4.0,0.0,sparkular-06, Figure 2 – Example Showven script for pyro and DMX   Example files for a mixed pyro and DMX show are available for download in Table 4.  The example show contains six DMX fixture positions and fourteen pyro positions.  The DMX fixture positions contain flashes of the Sparkular fixture with adjusted durations.  The DMX fixture positions also contain safety channel events covering the duration of the firing.   The timeline for the example show is shown in Figure 3.   Figure 3 – Timeline for example mixed pyro and DMX show.     Table 4 – Downloads Download link Explanation test-showven-fxcommander-sparkular01.fin Example show file test-showven-fxcommander-sparkular01.csv Example exported script file (CSV) fixture-setup01.pdf Example DMX Fixture Setup report