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.  

Tiltable row racks like the two Pyrolamas rack shown in Figure 1 have rows that fan out at various angles.  This rack structure contrasts with Fan row racks in which the tube holders fan out within each row.   Figure 1 – The rows of tiltable row racks aim forward and tilt left/right to make fans from the audience perspective.   Pre-configured vs. adjustable tilt rows If you specify the row angles of the rack before addressing the show and choose "Single-shot rack, fixed tube angles" for the rack structure in the "Create rack" dialog, then the rack is said to be "pre-configured".  The addressing algorithm will fill the rows with effects whose angles match the angles of the rows.  Figure 2 shows the "Create rack" dialog.  To set the row angles for a rack, fill in the "Row tilt" fields for the eight rows with tilt angles in degrees, following the angle convention that -90 is to the left, 90 is to the right, and 0 is up. If you leave the row tilt angles unspecified and instead choose the "Single-shot rack, adjustable tilt angle of each row" for the rack structure, then the addressing algorithm will define the row angles on the fly as it assigns firing system addresses to the shots.  Whenever you use the "Single-shot rack, adjustable tilt angle of each row" option, it is advisable to assign firing system addresses sorted by angle or tilt within each position, as shown in paragraph 2 of Figure 3, to guarantee that the addressing algorithm doesn't spread effects of the same angle across multiple rows when they could be in the same row, which could result in inefficient filling of the rack. In addition to the addressing sort order, the tube loading order option in the rack definition can affect the angles of the rows for adjustable tilt row racks, so for this kind of rack please follow both these guidelines: Set the tube loading order in the rack definition to "By rows, left to right" (which is also the default). When addressing, sort the addressing order by tilt or angle as the primary condition after Position. The reason for these guidelines is that the first effect assigned in each row will set the angle of the row.  The "By rows" loading order means the effects being addressed will fill out the first row, to the extent their angles are compatible, before moving on to the next.  The "Across rows" loading order means the effects being addressed will fill out the first tubes in each row before moving on to the second tubes, and so on.  The best approach to guarantee the rows are filled completely is to "fill" all the left-most rows first, and work your way to the right as the rows fill up, which requires (1) and (2).  Imagine if you have 25 shots to fill a 5-row rack, and your shots are in 5 angles, 5 shots each.  If you sort by angle but your tube loading order is "Across rows" instead of "By rows", then the first five shots would be assigned to the first tube in each of the five rows, forcing ALL of the rows to be the first angle.  Those first five shots would get racked and the next 20 would not fit in the rack because all the rows are aiming a single direction! These guidelines are not required for pre-configured tilt angle, only for adjustable tilt angles.  The guidelines still apply if you use the Re-arrange tubes in adjustable angle racks to avoid collisions option when addressing.   Pyrosure + Evolved example The Evolved racks are a kind of tiltable row rack that works with pre-wired pins.  The PyroSure firing system uses slats that are pre-wired individually to each row, requiring the pre-wired pins option "Sequential for each row" shown in Figure 2.    Since all the tubes in a row have the same angle, all the effects addressed to the same slat must therefore be the same angle.  The addressing configuration in Figure 3 adds the constraint in paragraph 3 that slats are restricted to a single angle.  If you are addressing for tiltable row racks with PyroSure, you need this constraint for the tiltable row racks.   Figure 2 – The Evolved rack for PyroSure requires the "Sequential for each row" option, since each row is wired to a slat.   Your show probably has other kinds of racks in it as well, though, and you may want to use other constraints and sorting criteria for other racks in the show.   The "Addressing > Address show" function applies a single set of addressing criteria for the entire show, so if you need different criteria for different parts of the show you need to use either 1) the "Addressing > Fill down addresses" function, or 2) addressing blueprints.   Addressing blueprints are rule sets or templates of the addressing criteria that look approximately the same as the "Addressing > Address show" dialog.  You can assign different addressing blueprints to different positions of the show, and then use the "Addressing > Address show using blueprints assigned to positions" instead of the "Addressing > Address show" function.  To use a different addressing blueprint for your tiltable row racks, you need to split off your tiltable row racks and their effects into their own positions, and then assign your custom addressing blueprint to those positions.   Figure 3 – The addressing configuration for PyroSure requires that each slat is restricted to a single angle.   In paragraph 3 of Figure 3, the two circled constraints connected by a red line restrict each module to a single rack, and each rack to a single module.  The combination of those two constraints creates a 1:1 relationship between modules and racks.  This is the necessary configuration for using PyroSure firing system with the Evolved tiltable row racks. The PyroSure slats are pre-wired to the tubes in the tiltable row rack in a pre-defined (and obvious) order, beginning with pin 1 at the top and pin 4 at the bottom for each row, since each row is pre-wired to a slat with four pins.  The "Sequential for each row" option shown in Figure 2 is the choice that will guarantee that pin layout.  There are other options that are applicable to other firing systems, but the "Sequential for each row" option is the correct choice for PyroSure because PyroSure uses a separate slat for each row.  The various pre-wired pin options are all illustrated in Pre-wired pin options.  The illustration of "Sequential for each row" is shown here in Figure 4.   Figure 4 – The "Sequential for each row" option works for firing systems like PyroSure that assign a separate module or slat to each row.    FireOne example The setup for FireOne is slightly different from PyroSure because FireOne doesn't use slats for its addressing scheme.   Figure 6 illustrates the natural pin pattern for pre-wiring a FireOne module to a tiltable row rack with the same number of tubes (see Pre-wired pin options for other options).   Figure 6 – The "Sequential by rows, left to right" option works if a single module and pin range cover the entire rack.    You can select this "Sequential by rows, left to right" pre-wired pins option in the "Create rack" dialog, as shown in Figure 7. Figure 7 – The tiltable row rack configuration for FireOne can use the "Sequential by rows, left to right" option.   The FireOne system doesn't use slats in its addressing scheme, so the addressing configuration for tiltable row racks using FireOne doesn't specify anything in the slats line of paragraph 3 of the addressing configuration shown in Figure 8.   Figure 8 – The addressing configuration for FireOne doesn't have constraints for slats, because there aren't any.  

When you define a rack with the "Create rack" function you have the option specifying a "Pre-wired pins" constraint, which pre-defines the one and only pin number that can go into each tube holder of the rack.  This feature is required if your racks physically are pre-wired to the firing system.  What is less well known is that using the pre-wired pins option to put the pins into an optimal order can be useful even for racks that are not pre-wired to the firing system.  By forcing the pin numbers to be arranged in an order that is more understandable for the crew, or that results in cleaner wiring layouts, or that puts shots of the same product type into a straight sequence of pins, you can save the crew time and reduce the chance of error. To complement this section, please see Racks with pre-wired pins and Shoot sites with pre-wired pins for example uses of pre-wired pins.  The section Rack “row” and standard orientation explains the orientation of rows (vertical). The "Create rack" dialog has eleven options for pre-wired pins.  The first nine options are specific patterns that correspond to common use cases.  The last two -- "Specified by Custom Part Field' and "Specified by Custom Rack Field" -- enable you to specify any arbitrary pattern for the pins by typing in a list of pin numbers separated by commas in the Custom Part Field of the rack in the effects window, or in the Custom Rack Field of a rack instance in the rack layout view.  If you want to mark off any tube holders as unusable, you can simply assign them large pin numbers like 99 that don't exist on your firing system.   Figure 1 – The "Pre-wired pins"  options on the "Create rack" dialog   The following figures illustrate the various pre-wired pin pattern options.  In all of these figures, the racks are oriented in the vertical row orientation, starting with row #1 on the left.  Since single-shot racks usually have rows aiming sideways, you would probably change the standard orientation of these racks to "Rows or horizontal on screen (most single-shot racks)", as described in Rack “row” and standard orientation.   Figure 2 – "By rows, left to right" (the rack has eight vertical rows, starting with the row on the left)   Figure 3 – "Across rows, left to right"   Figure 4 – "By rows, left to right, half and half" (requires two modules or slats because it includes two pin ranges)   Figure 5 – "Across rows, left to right, half and half" (requires two modules or slats because it includes two pin ranges)   Figure 6 – "By rows, right to left" (pattern begins with the right-most vertical row)   Figure 7 – "Across rows, right to left"   Figure 8 – "By rows, right to left, half and half" (requires two modules or slats because it includes two pin ranges)   Figure 9 – "Across rows, right to left, half and half" (requires two modules or slats because it includes two pin ranges)   Figure 10 – "Sequential for each row" (requires eight modules or slats because it includes eight pin ranges, one for each row)