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

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

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

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

To create and export a script for the FireByWire firing system, please follow these three steps: Design the show. Address the show ("Addressing > Address show"). Export the script ("File > Export > Export firing scripts"). Step 3 creates the script file, which is a CSV file that you can import into your firing system, or edit in a text editor.   Figure 1 – The FireByWire firing system   The exported script is a human-readable text file that contains little more than the essential information for a firing system controller to fire the show -- the ignition time, effect time, channel, position, and effect name.   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 of data fields separated by commas, and a few header rows.   The script contains a variable number of columns that depends on the number positions, enabling each position's data to shown in a separate pair of columns to represent the effects and channels of the shots on the position.  The special characteristics of the script are shown in the following table:   Table 2 – Special characteristics Special characteristics Description Sort order of rows Rows are sorted by ignition time (despite the fact that the effect time is the first field in each row). Columns Scripts contain three columns (row number, effect time, and event time), plus a pair of columns for each position to hold the effects and channels of shots at the position. What rows represent In FireByWire scripts exported by Finale 3D, each row identifies a unique firing pin ignition at a single position (i.e., unique module-slat-pin-position).  Although FireByWire scripts are capable of representing shots at multiple positions in the same row (since the script format has columns for each position), Finale 3D keeps each shot on a separate row in its exported FireByWire scripts. Module/slat/pin addresses The FireByWire system employs modules with 4 slats of 8 or 16 pins each, for 32 or 64 pins in total per module.  Special characters Fields include ASCII characters other than: ' , ; " tab and newline and other control characters. When you export a firing script for FireByWire, Finale 3D presents an "Export Options" dialog with options for different versions, as shown in Table 3.   Table 3 – Export options Option name Description Version Choose the 1ms time resolution or 100ms time resolution script version.     Each script row has the fields shown in Table 4.   Table 4 – Specifications of script fields Field name Description Row number The row number count, beginning with 1. Burst The time of the visual impact of the effect, such as the break of the shell. Format is MM:SS.DDD. Launch The exact time of the firing system's "ignition event" (application of a voltage to a pin) that ignites e-matches or triggers a sequencer that ultimately leads to the ignition of effects. Format is MM:SS.DDD. <First position name> The effect description of a shot in the first position. Channel The channel of a shot in the first position, in the format MMM-SP, where MMM is the module, beginning with 001, and S is the slat from 1-4, and P is the pin letter from A-P. <Next position name> The effect description of a shot in the next position. Etc. Additional columns for the remaining positions and their channels. The example script with three positions in Figure 2 below and the corresponding exported script in Figure 3 illustrate the arrangement of position columns in the FireByWire script export format.   Figure 2 – A script showing the module and slat numbers in the "Rail" column and the pin letter in the "Pin" column.   The three positions in the script shown in Figure 2 become pairs of columns in the FireByWire exported script, shown in Figure 3.   FireByWire script Exported from Finale MLE Pyrotechnics C:UserswillDocumentstest_firebywire01.wav x,Burst,Launch,Pos-01,Channel,Pos-02,Channel,Pos-03,Channel 1,00:05.000,00:02.760,Green Chrysanthemum,001-1A,,,, 2,00:06.000,00:03.760,,,Green Chrysanthemum,002-1A,, 3,00:07.000,00:04.760,,,,,Green Chrysanthemum,003-1A 4,00:09.883,00:07.643,Green Chrysanthemum,001-1B,,,, 5,00:10.883,00:08.643,,,Green Chrysanthemum,002-1B,, 6,00:11.883,00:09.643,,,,,Green Chrysanthemum,003-1B 7,00:15.731,00:13.491,Purple Chrysanthemum,001-1C,,,, 8,00:15.731,00:13.491,,,Purple Chrysanthemum,002-1C,, 9,00:15.731,00:13.491,,,,,Purple Chrysanthemum,003-1C Figure 3 – Exported FireByWire firing system script corresponding to the script of Figure 2   Table 5 – Example files Download link Explanation test_firebywire.csv Example exported file  (CSV) test_firebywire.fin Example show file

Effects fit into racks of the same size that are also the right kind of rack, based on the effect's "Type" field.  Candles fit into candle racks.  Single-shots fit into single-shot racks.  Cakes fit into cake racks.  Shells, mines, and comets fit into mortar racks.   Obviously single-shots can also be shells, mines, or comets in the physical world, but effects have a single Type in the Finale 3D software, and that is what determines what kind of rack the effects fit into (see Why is ‘Type’ so important? What depends on it?). In practice, you may have reason to put candles or single shots into your mortar racks, notwithstanding their Type.   You may also want to put slice cakes in single-shot racks, or ground items or single-shots in cake racks. The practice of putting single-shots and candles in mortars is called sleeving.  Finale 3D extends the meaning of the term sleeving to include all circumstances of putting an effect into a rack of a different Type.   Table 1 – Using sleeving to put an item into a different kind of rack Original type of the effect Original kind of rack that it goes into Possible to "sleeve" the effect Kind of rack the effect goes into if it is sleeved single_shot Single-shot rack YES Mortar rack candle Candle rack YES Mortar rack shell, comet, mine Mortar rack YES Mortar rack (no change) cake Cake or ground rack YES Single-shot rack (makes sense for slice cakes) ground Cake or ground rack YES Single-shot rack (example: ground strobe) other_effect None YES Single-shot rack   To sleeve effects in Finale 3D, you simply set the "Sleeve" field of the effects to the size in the rack you want them to fit into.   Then when you address the show or drag and drop pins in the rack layout view, the effects will fit into racks of the specified size, no matter what their actual Type and Size are.   Figure 1 – Example of six 2" roman candles and some 3" racks that would be nice to put them into.   The example shown in Figure 1 has six 2" candle effects that do not fit into the 3" mortar racks because of their Type and Size.  Right-click on the effects in the script window to set their Sleeve field, as shown in Figure 2.   Figure 2 – Right-click the effects in the script to set their "Sleeve" field to 3" to make them fit into 3" racks.   The menu item will bring up the dialog shown in Figure 3.  You can select multiple effects and right click on any of them to set the Sleeve of all of them at once, or if you know that you want to sleeve all similar effects in the entire show, you can right-click on any one of them and check the "Apply to all instances of this effect" box in the dialog.   Figure 3 – Check the "Apply to all instances of this effect" box to apply to all effects with the same part number.   The Sleeve field is one of the columns in the script table.  It is hidden by default.  From the blue gear menu you can unhide the column to look at the Sleeve values, as shown in Figure 4.  Inches and millimeters are compatible representations for sleeving effects, so long as they are within a small tolerance.  For example, 75mm and 76mm sizes both fit into 3" rack tubes as well as 75mm and 76mm tubes.   Figure 4 – Unhide the "Sleeve" column to examine the sleeve field of the effects in the show, which are blank by default.   Having set the Sleeve fields to 3", the empty racks shown in Figure 1 will hold the candles without errors when you re-address the show.  Figure 5 shows the result after sleeving and re-addressing.   Figure 5 – After re-addressing, the candles with the 3" sleeve fields  will fit into 3" mortars.   Sorting by size in the addressing dialog The sorting fields in the addressing dialog include a number of options related to size, as shown in Figure 6.  The sorting options that have the same name as a script column will sort by the unadjusted data value in that column.  Thus the "Size" sorting option sorts the sizes without taking into account the sleeve size.  The "Size -- XXX" options just above the blue row in Figure 6 sort by size for specific effect types while doing nothing for effects of other types.  The size and the effect type for those options refer to the "Size" and "Type" columns' data values, unaffected by sleeving.  With respect to these options, a 50mm single-shot is still a 50mm single-shot, even if you have sleeved it to go into a 3" mortar rack.   Figure 6 – The size sorting options in the addressing dialog do not take into account sleeve size, except for the "Size Or Sleeve" option.   Slice cakes in single-shot racks Sleeving changes the kind of rack that an effect is compatible with, and it changes the size of the mortar or tube or cake slot in the rack that the effect occupies, the changed size being the sleeve size.  Some single-shot racks have a "Max. usable row length" constraint that limits the number of effects that can fit in a rack row by the sum of their sizes, which must not exceed the usable row length. Sleeving changes the kind of rack that an effect is compatible with, and it changes the size of the mortar or tube or cake slot in the rack that the effect occupies, the changed size being the sleeve size.  Some single-shot racks have a "Max. usable row length" constraint that limits the number of effects that can fit in a rack row by the sum of their sizes, which must not exceed the usable row length. Cakes that are sleeved to go into single-shot racks are usually slice cakes comprising a single row of tubes.  As a special mechanism, sleeved cakes will require and occupy an entire rack row if the rack has a "Max. usable row length" constraint, rather than consuming just part of the row length. Imagine a slice cake that consists of 10 tubes with 1" diameter.  Its footprint is wide and rectangular, approximately 1o or 11 inches by 1".  If you put that slice cake in a single shot rack, the slice cake slides into the row, aligning length-wise with the row.  It consumes 10 or 11 inches, not 1". Since a common practice is for slice cakes to consume entire rows of single-shot racks, the special mechanism for sleeving cakes implements just that -- sleeved cakes consume the entire row of racks with "Max. usable row length" constraints.  Thus to sleeve a 10 tube slice cake with 1" tubes into a single-shot rack you would typically use a sleeve size of 1", not 10 or 11 inches.  If the rack has a min/max size constraint, the 1" will fit appropriately into the min/max range of the rack.  If you want, you can cancel out the special mechanism and set an explicit row length consumption for a cake by settings its "rackRowLengthConsumption" property in the Physical Specifications column in the effects window (see Variable tube size racks with row length constraint). Unlike single-shots and shells, cakes in Finale 3D are considered non-rotationally symmetric (see Why is ‘Type’ so important? What depends on it?).  A shell doesn't look any different if it is rotated inside the mortar, whereas a cake might.  A sideways fan cake is different from a forward/back fan cake.  A left-to right fan cake is different from the same cake rotated 180 degrees. A slice cake needs to align with the row of the single-shot rack that contains it in order to fit, physically: a long, skinny slice cake fits into a long, skinny row.  Because cakes are non-rotationally symmetric, their orientation in the show matters, and the rack that contains them must be oriented compatibly with the cake orientation.  The actual requirement is that the sum of the cakes' PAN and SPIN angles is required to match the orientation of the rows in the single-shot rack they are sleeved into, plus or minus 180 degrees.  For example, if the slice cake is oriented facing forward such the fan faces the audience, the single-shot rack that it fits into needs to be rotated 90 or 270 degrees so that its rows are sideways, aligned with the forward-facing, wide, rectangular cake.    

The "Pre-Wired Rails" field of the racks in the rack layout view enables you to restrict racks to using specific rails.  In most circumstances it is best to leave the Pre-Wired Rails field empty, so the addressing functions can assign effects and firing system pins to racks optimally for the constraints you've defined.  But in some circumstances like fixed-use venues or theme parks with firing systems pre-wired to the racks, you don't have a choice -- if the firing system module is pre-wired to a specific rack, then you had better make sure the addressing functions abide by that constraint. The rack layout in Figure 1 is an example from a theme park that has the racks wired up to the firing system in a permanent configuration, so this is an example in which it is necessary to specify the Pre-Wired Rails to ensure the racks end up with the right modules (rails and modules are the same thing for firing systems like PyroDigital that don't partition the module's pins into slats).      Figure 1 – The "Pre-Wired Rails" field of racks restricts the rack to one or more specified rails.   The Pre-Wired Rails field in the rack layout view is usually on the far right of the table.  To see it, you will probably need to hide other columns with the blue gear menu, to make room.  Once you can see and edit the Pre-Wired Rails field, enter into it the list of rail addresses that a rack is permitted to use.  In the Figure 1 example, each rack has only a single tube, so each rack is bound to a single module.  Other use cases like large single-shot racks may require a list of permitted rail addresses.  You can type a list of addresses into the field, separated by commas. It is okay to use the same address for multiple racks.  The meaning of the Pre-Wired Rails field is that the rack is restricted to the rail addresses from the given list.  The constraint is only in that direction, though.  It doesn't imply that the rail addresses are restricted to that rack.   Figure 2 – The "Pre-Wired Rails" of the rack must be chosen from the "Pre-Assigned Rails" of the position.   The Pre-Wired Rails field must only contain rail addresses that are pre-assigned to the position by way of the "Add rail" or "Edit rails" buttons at the bottom of the rack layout view or in the position properties (the "Pre-Assigned Rails" field of the position, as shown in Figure 2).  If the Pre-Wired Rails field of a rack contains an address that is not in the Pre-Assigned Rails field of the position, the Pre-Wired Rails field will be ignored.  

When you drag a pin number to a rack in the rack layout view, the pin number may display in red in its new position, indicating an error.  There are a number of possible explanations, such as: the effect with that pin number is the wrong size or wrong angle for the tube.  If the cause of the error isn't obvious, you can right click on the pin number and select the menu item, "Why is this tube red?" to see an explanation.   Figure 1 – Right-click on a tube and select "Why is this tube red?" for an explanation!   The full list of possible explanations is given in Table 1.  The explanations don't require further elaboration, except for one: when the effect angle doesn't match the tube angle, at times it can be difficult to reason why.  Effect angles are based on the Pan, Tilt, and Spin columns in the script, to enable the effect to aim in any direction and with any spin.  Effects like shells and mines are rotationally symmetric around the axis of their trajectory, so spin doesn't matter for those types of effects.  But spin does matter for cakes, which may look different if you rotate them 180 degrees to face them the opposite direction, for example. Since the left/right Tilt of the effect is by far the most common angle adjustment, most of the user interface and tool tips display only the Tilt angle, so as not to overwhelm you with three numbers when one is usually sufficient.  But sometimes when you are trying to figure out why an effect is highlighted in red in a tube, you do need to look at all three angles.  It is no favor to you in this circumstance that the user interface omits the other angles.  So if you are having trouble understanding why an effect's angle doesn't match the tube, try un-hiding the Pan, Tilt, and Spin columns in the script window so you have all the information at hand to get to the bottom of the problem. Table 1 – Possible explanations Attribute Explanation Rack Type Incompatible Rack Type.  Look at the 'Rack Type' column for the effect in the script, and compare to the 'Rack Type' column for the rack in the table below. Part Number The effect is missing a part number. Part Number The effect's part number does not match an effect in the Per-show effects. Type The type of the effect does not match rack. For example, effects with type 'single_shot' go into single-shot racks; effects with type 'shell' or 'comet' go into mortar racks. Look at the effect's 'Type' column and compare to the kind of rack it is placed in. Pre-Wired Pins The rack's pre-wired pins specify a different pin number for this tube. Edit the rack's VDL to examine its 'Pre-wired pins' constraint. Size The effect sizes in this row of tubes add up to more than the length of the row. Edit the rack's VDL to examine its 'Max. usable length per row' constraint. --- The rack does not have any available tubes. --- The tube is used by another effect. --- The rack does not have any available tubes. Size The effect size is not compatible with the tube size. Size The effect size is not compatible with the min/max size range of rack. Angle The effect angle does not match tube. The effect angle is based on the Pan, Tilt, and Spin columns in the script table. Pre-Wired Rail The address of the effect does not match rack's pre-wired rails. Look at the 'Pre-Wired Rails' column for the rack in the table below.   What red pin warnings do not take into account The red pin warnings test whether the item's properties like Size and Type and Rack Type are compatible with the rack's definition, taking into consideration sleeving and Rack Type Part Numbers.  The warnings also test the pre-wired pins and pre-wired rail constraints if the rack has these constraints.  The warnings do not, however, take into account the addressing constraints from the addressing dialog or blueprint.    Thus the red pin warnings can show you some of the reasons that an item may not get assigned to a rack by the addressing function, but they may not show you all the possible reasons. If you think about it, the red pin warnings couldn't possibly take into account the addressing dialog or blueprint constraints, because the red pin warnings can only depend on the constraints of the items and racks as they stand.  The addressing dialog and blueprint constraints are merely inputs to the addressing algorithm that are not recorded in the items and racks themselves.