The analyze timecode dialog and its timecode log file show you a summary and the actual timecode frames that are in a song file or that have been received as timecode input from an external source.  For song files, the summary is convenient for many everyday uses since a human can't tell from looking at the waveform or listening to the timecode channel of an audio file what the timecode range of the song is.  For song files and for timecode input, the log file is useful for debugging, answering such questions as whether the timecode signal has any jumps or glitches, how long it should take a device to lock onto the timecode, is its frame rate consistent, when does it start or end, etc. The "File > Tools > Analyze timecode in soundtrack file..." function works for all firing system versions of FSK (see FSK) and for all the common variations of SMPTE (see SMPTE).  The function examines the file, testing whether it contains valid timecode in any of the timecode formats.   Alignment on the timeline The timecode information dialog looks like the dialog of Figure 1.  If you use the function, "File > Tools > Analyze timecode in soundtrack file...", you'll get a dialog that looks like this for any song file you choose, WAV for MP3.  The dialog confirms that the song file actually does contain a timecode signal, and tells you what channel it is on.   Figure 1 – The best alignment for the song is usually -- but not always -- the same as its first frame time.   The dialog tells you the best alignment for the song on the timeline.  Usually, the best alignment for the song on the timeline is the time of the first frame in the timecode signal, but depending on how the song file was created, that may not be the case. The timecode signal in the file may not start at exactly the beginning of the file, and may not start with a valid frame.   If the timecode channel was cropped to a timecode range and copy / pasted into the song in an audio editor, there's a good chance that the first frame may be partially clipped and thus invalid.  There's also a chance that a copy / pasted timecode signal might not be pasted at the exact beginning of the song.  In all these scenarios, the first valid frame of the timecode might not correspond to the beginning of the file. Imagine that the first frame of the timecode is 04:00:00:00 but that the timecode channel happened to be pasted at an offset 1 minute into the song.  Then the proper alignment of the song based on its timecode would be 4 hours minus 1 minute, or 03:59:00:00.  Importing the song at that position on the timeline causes its 04:00:00:00 frame to align with exactly 4 hours on the timeline.   Alignment of FSK The firing system versions of FSK follow de facto alignment conventions specific to each firing system.  As described in FSK, the conventions do not match up the data packets to the times they represent exactly to the millisecond.  They are a little bit off.  Depending on the firing system, the data packets in the FSK end anywhere from 0 ms to 100 ms earlier than the times the data packets are meant to represent. The analyze timecode dialog and its log file show the actual alignment of the data packets in the examined file, but the "Best alignment on timeline" shown in the dialog and used to align songs when importing them is adapted to keep consistent with the firing system reference FSK files:  If the calculated data packet alignment is less than or equal to 100 ms, the "Best alignment on timeline" is taken to be simply, "Beginning of timeline" rather than the actual delta necessary to align the data packets to the times they represent.   That's what you want, so that's "best."   Frame rate and drop frame SMPTE timecode doesn't contain the frame rate in its encoded data explicitly, but it does contain a flag indicating whether the encoded frames are counted using the drop frame system (DF) nor non-drop frame (NDF), as explained in Timecode frame rates and drop frame.  The frame rate of SMPTE timecode is implicitly the frequency of the frames in the encoded signal.  The dialog of Figure 1 displays the frame rate and DF/NDF for song files based on this information. For timecode input from an external source that comes into the computer as MIDI MTC timecode, Finale 3D displays the same information but it comes from a different calculation.  A MIDI MTC signal does contain an explicit frame rate in its encoded data, which Finale 3D uses, but it does not contain an explicit drop frame flag.  Finale 3D determines the drop frame system of MIDI MTC timecode input based on the frame rate (inferring that any frame rate other than 29.97 fps is NDF) and based on the presence or absence of the frame numbers that don't exist in the drop frame counting system.   Bad frames, jumps, and pauses Since timecode can be added to a song file using an audio editor, there's no guarantee that the timecode signal starts at the beginning, or is contiguous.  A sound track can be constructed in an audio editor that has different sections with different timecode ranges in them and gaps in between.  The timecode ranges may not even be in chronological order. When Finale 3D reads the timecode of a song file, it keeps track of the number of gaps in the timecode frame sequence, and of discontinuous jumps.  Finale 3D also keeps track of the number of bad frames, which are frames that are corrupted or whose encoded times are clearly not part of any progressing sequence of frames.  It is not uncommon to see frames with times of 30:00:00:00 or 00:00:00:00 in the middle of a timecode sequence that is nowhere near 30 hours or the beginning of the show, depending on the quality of the encoded timecode signal. You may have no idea where the timecode signal in a file or from an external source originated -- a copy /pasted WAV file?  A file that has been compressed as an MP3?  A hardware device?  A recorded or broadcasted audio signal?  The bad frame count in the timecode information dialog gives you an idea of the quality of the signal. Since most firing systems and other production hardware devices lock on and track to a timecode signal while using an internal clock to provide smooth playback, the presence of bad frames in the timecode signal is not necessarily alarming.  Look at the count of jumps and pauses.  If those numbers align with your expectations, then the timecode signal is probably fine even if it has hundreds of bad frames.  But the bad frames may be a reason for you to investigate further.   Timecode log file The timecode log file shows the actual frames encoded in the song file or received as input.  The file may be long, as even 20 minutes of 30 fps is 36000 frames.  An excerpt from a log file is shown in Figure 2.   // Format: [timestamp] (deltas from last msg: timestamp, frame) received msg HH:MM:SS:FF @ received frame rate + timecode input offset -- > interpretation [0.018] (+0 +0) 00:00:59:28 @ 30 fps NDF + 0ms -- > 00:00:59:28 30 fps NDF < non-tracking > [0.052] (+34 +94) 00:00:59:29 @ 29.97 fps NDF + 0ms -- > 00:00:59:29 29.97 fps NDF < non-tracking > [0.085] (+33 +33) 00:01:00:00 @ 29.97 fps NDF + 0ms -- > 00:01:00:00 29.97 fps NDF < non-tracking > [0.118] (+33 +33) 00:01:00:01 @ 29.97 fps NDF + 0ms -- > 00:01:00:01 29.97 fps NDF < non-tracking > [0.152] (+34 +34) 00:01:00:02 @ 29.97 fps NDF + 0ms -- > 00:01:00:02 29.97 fps NDF < non-tracking > [0.185] (+33 +33) 00:01:00:03 @ 29.97 fps NDF + 0ms -- > 00:01:00:03 29.97 fps NDF < non-tracking > [0.218] (+33 +33) 00:01:00:04 @ 29.97 fps NDF + 0ms -- > 00:01:00:04 29.97 fps NDF < non-tracking > [0.252] (+34 +34) 00:01:00:05 @ 29.97 fps NDF + 0ms -- > 00:01:00:05 29.97 fps NDF < locking > [0.285] (+33 +33) 00:01:00:06 @ 29.97 fps NDF + 0ms -- > 00:01:00:06 29.97 fps NDF [0.318] (+33 +34) 00:01:00:07 @ 29.97 fps NDF + 0ms -- > 00:01:00:07 29.97 fps NDF [0.352] (+34 +33) 00:01:00:08 @ 29.97 fps NDF + 0ms -- > 00:01:00:08 29.97 fps NDF Figure 2 – Example log file The log file lines begin with the time stamp of each received message (frame), followed by the time deltas from the previous message measured in real world time and in the difference between the HH:MM:SS:FF encoded times in the messages.  If those two time deltas are exactly the same, then the encoded timecode frame sequence is progressing in synch with real world time. In practice, the time deltas aren't always in synch exactly, for a number of reasons including latency and burstiness in the timecode event processing for timecode input from an external signal.  The second message in Figure 2 is an example in which the deltas between the times represented by the frames are not the same (+34 versus +94 milliseconds).  But if you compare the frames 00:00:59:28 to 00:00:59:29, that would seem to be a single frame difference, or about 33ms.  Where did the +94 come from? Looking more carefully at the first and second messages, the first message is interpreted to be at 30 fps, whereas the second message at 29.97 fps.  Recall that SMPTE timecode does not contain an explicit frame rate in the encoded signal.  The frame rate is determined based on the frequency of the encoded frames in the signal.  The difference between 29.97 fps and 30 fps isn't much, so after a single frame, the signal doesn't yet contain enough precision for the reader to ascertain the frequency exactly.  It happens, in this example, that the reader interprets the first frame as 30 fps, and the second (more accurately) as 29.97 fps.  The real world time of 00:00:59:28 in 30 fps is 59.933 ms.  The real world time of 00:00:59:29 in 29.97 fps is 60.026 ms.  The difference?  94 ms. To the right of the arrow is the interpretation of the frame, which begins the same as the frame payload itself for song files.  For MIDI MTC timecode input, the interpretation includes the DF/NDF determination that is not present to the left of the arrow (not shown in this example). The bracketed comment in the interpretation, such as <non-tracking> and <locking> show how the timecode reader interprets the frame in the context of the surrounding sequence of frames.  You can see that it takes a few received frames for the timecode reader to lock onto the sequence.  Other hardware devices may take more or fewer frames to lock on but follow a similar sort of pattern.  Other comments such as <bad> and <jump> and longer comments for timecode input like <pausing because no messages in XXX ms> are also possible.  

Timecode is an audio track that can be interpreted by your computer or firing system as a sequence of time stamps.  Time stamps are typically written as HH:MM:SS:FF.   Table 1 – SMPTE time stamps HH MM SS FF Hours 0-23 Minutes 0-59 Seconds 0-59 Frames 0-29 (depends on frame rate and drop frame) You can think of timecode as a recording of a fast talking human clock reader barking out: “0 hours, 0 minutes, 0 seconds, 0 frames, <short pause>, 0 hours, 0 minutes, 0 seconds, 1 frame, <short pause>, 0 hours, 0 minutes, 0 seconds, 2 frames, etc.”  The clock reader would need to be talking fast because frames are typically about 1/30th of a second.  So if the clock reader were reading every frame, he'd be talking very, very fast, with each time stamp utterance taking just a fraction of a second. Timecode, however, is meant for computers and devices like firing systems to understand, so the audio encoding of these time stamps is in a protocol that is efficient for computers to decode, not humans. There are several protocols for encoding timecode in an audio signal, some that are specific to firing systems or other hardware devices, and some that are open standards.  SMPTE timecode is an open standard timecode encoding that is recognized and understood by almost all timecode processing hardware, so often when people say "timecode" they mean more specifically "SMPTE timecode".  This article is discusses the frame rates and frame numbers specifically for SMPTE timecode (see LTC details).   Frame rates The frame rate of SMPTE timecode is simply the number of the time stamps per second in the signal.  The commonly supported frame rates are,   Table 2 – SMPTE frame rates Frame rate Description 30 FPS American television system ATSC 29.97002997 FPS (or "29.97" for short) American television system NTSC 25 FPS European television system PAL 24 FPS Film The SMPTE time stamps do not contain within them any explicit indication of the frame rate.  If you played a SMPTE timecode track that was recorded at 30 FPS at 0.1% slower than the normal playback rate you would have, identically to several decimal digits, 29.97002997 FPS SMPTE (the non-drop frame version).  The exact frame rate of 29.97002997, which is a repeating decimal string, is 30000 frames / 1001 seconds, abbreviated as "29.97 FPS SMPTE" for short. The "drop frame" version of timecode, for readers who are looking ahead a paragraph or two, does not change the frame rate of the SMPTE time stamps.  Thus in Finale 3D, the "Show > Show settings > Set timeline snap-to resolution" includes only the frame rates of Table 2 and a few unrelated options; there is no mention of drop frame or non-drop frame in the timeline snap-to resolution options because the timeline, like a ruler, is delineated in equally spaced units.  A ruler is delineated in 1/16th inch units on the imperial side and millimeters on the metric side.  The timeline is delineated in milliseconds by default or the snap-to resolution chosen by the user, which is equally spaced units of 1/30th of a second or approximately 1/29.97ths of a second or 1/25ths of a second or 1/24ths of a second. Figure 1 – Timeline snap-to resolutions include the four SMPTE timecode frame rates. Frame numbers The 30 FPS SMPTE time stamps count in frames sequentially from 0 to 29.  Thus the stream of HH:MM:SS:FF time stamp values progresses in synch with the progression of time in the real world: after 30 frames at 30 FPS, one second has gone by in the real world and one second has gone by in the HH:MM:SS:FF time stamp representation. The 25 FPS and 24 FPS SMPTE time stamps count in frames sequentially from o to 24 and from 0 to 23 respectively.  So they also progress in synch with time in the real world. If the 29.97 FPS SMPTE time stamps count in frames sequentially from 0 to 29, just like the 30 FPS time stamps, then the time stamp values will not remain in synch with time in the real world.  29.97 FPS is slightly slower than 30 FPS, so the time stamp HH:MM:SS:FF in the 29.97 FPS stream following a sequence of 30 frames would say that exactly one second has transpired while in reality slightly more than one second has transpired. Projecting this difference out to a longer period of time, after 10 minutes the 29.97 FPS time stamps would fall behind time in the real world by 0.6 seconds.  If you set your watch by the time stamp values, your watch would be running slowly.  If you executed a 30 FPS firing system script using sequential time stamps playing back at 29.97 FPS, the script would play back slowly, and would become out of synch with the music. To correct for this difference a new, not entirely sequential counting system was invented to count the frames of 29.97 FPS SMPTE.  The new counting system counts from 0 to 29 for most seconds, but skips frame 0 and frame 1 for some seconds, jumping directly from frame 29 of the previous second to frame 2 of the next second.  This counting system is called "drop frame."   SMPTE 29.97 FPS DF (drop frame) SMPTE 29.97 FPS drop frame, or "29.97 FPS DF" for short, is a variation of 29.97 FPS SMPTE that keeps closely in synch with the progression of time in the real world by counting frames in a manner that is not entirely sequential.  To disambiguate whether frame numbers in SMPTE time stamps are counting in drop frame (DF) or non-drop frame (NDF), the punctuation of the HH:MM:SS:FF notation is adjusted for DF, substituting a semicolon for the last colon.   Table 3 – Notation for the two SMPTE 29.97 FPS versions Frame rate and version Time stamp notation 29.97 FPS DF HH:MM:SS;FF 29.97 FPS NDF HH:MM:SS:FF Both the DF and NDF version of 29.97 FPS SMPTE have a frame rate of 29.97 FPS.  The difference is the NDF version counts all frames sequentially from 0 to 29, while the DF version skips in its counting sequence from frame 29 of one second to frame 2 of the next second for some of the seconds. The HH:MM:SS;FF time stamps of the DF stream count sequentially and lose ground against real world time for the first minute of play, and then at one minute the counting sequence skips from 00:00:59:29 to 00:01:00:02.  The 00:00:59:29 time stamp is slightly later than 59 seconds and 29/30ths in real world time, but the 00:01:00:02 time stamp, which is immediately following, catches up.  During every minute that passes, the DF time stamps lose ground against real world time, and then at the end of every minute the DF time stamps skip two frame numbers to catch up. The catching up mechanism of skipping two frame numbers slightly overcompensates for the lost ground of the preceding minute, so very gradually the catching up mechanism gains ground against real world time.  To avoid gaining ground continually, the DF frame counting system doesn't skip the two frames at the beginning of minutes that are divisible by 10, which includes the first minute of play at minute zero. In the SMPTE timecode signal, the time stamps contain a "drop frame" flag along with the HH:MM:SS:FF fields, indicating whether the frame counting is sequential or following the drop frame counting system.  The drop frame flag is defined for both 29.97 FPS SMPTE and also for 30 FPS SMPTE, though uses for 30 FPS DF are rare since it doesn't keep in synch with real world time.  More often than not if you see the words "30 FPS DF" the intended meaning is "29.97 FPS DF", so to avoid confusion Finale 3D does not support 30 FPS DF.  The NDF version of 29.97 FPS timecode also doesn't keep in synch with real world time, but there are applications that use it so Finale 3D does support it.  The list of frame rates and versions that Finale 3D supports for effect time representations is in Figure 2.  You can select the time format from "Show > Set show information..." or "Show > Show settings > Set effect time format". Figure 2 – Effect time formats include the four SMPTE timecode frame rates and both versions of 29.97 FPS: DF and NDF     SMPTE 29.97 FPS NDF (non-drop frame) SMPTE 29.97 FPS non-drop frame, or "29.97 FPS NDF" for short, progresses through HH, MM, and SS significantly slower than the progression of time in the real world (called "wall clock" time) by 1.2 seconds for every 20 minutes.   It advances the HH, MM, and SS by one second after the passage of every 30 frames, but the frames are playing back at only 29.97 per second, so the HH, MM, SS advance at a rate of 29.97 / 30 as fast as wall clock time. If a firing system controller is being driven by SMPTE 29.97 NDF timecode, it will trigger the script events at this slow rate.  Some controllers have an option to compensate for the slower-than-wall-clock rate of SMPTE 29.97 NDF, but compensation in the controller isn't well suited for circumstances like concert soundtracks with multiple songs beginning at different agreed upon SMPTE times since the songs don't necessarily use the same timecode format, and since the operator of the controller may not know in what order the songs will be played.  For circumstances like these, Finale 3D offers better suited options to adjust the event times in the script for SMPTE 29.97 NDF, described here: SMPTE 29.97 NDF (non-drop frame). When adding a soundtrack to your show, if you elect for Finale 3D to split the soundtrack's timecode sections apart and automatically position them independently on the timeline, Finale 3D will position them on the timeline at the wall clock time interpretation of the SMPTE HHMMSSFF timestamps, even if the SMPTE timecode sections internally are in SMPTE 29.97 FPS NDF.  Similarly, if you slave the playhead in Finale 3D to external timecode input (see Timecode basic instructions), the playhead will be positioned according to the wall clock time interpretation of the timestamps.   Timecode on the timeline You can change the effect time format in Finale 3D to any of the frame rates and versions in Figure 2.  The timeline, which is delineated in real world time as far as hours, minutes and seconds, shows the playhead time in the effect time format.  If you are scripting in an environment in which you are communicating points of the show with other people using the timecode times, it is most convenient to set both the timeline snap-to resolution and the effect time format to match the timecode of the show.  That will cause the playhead to snap to the times corresponding to valid frames of the show and to display them correctly.  Using the ruler analogy, the playhead would be snapping to the 1/16th inch or 1mm marks on the ruler, and would never lie in between the marks. If the playhead does lie in between the frames of the effect time format, the playhead's time will display with an additional "+ms" remainder to reflect the exact time in milliseconds.  Since the timeline's hours, minutes, and seconds are in real world time, while the playhead's time is in the effect time, you can see on the timeline exactly how 29.97 DF or NDF get out of synch with time in the real world.  It is analogous to the ruler that shows imperial markings on one side and metric markings on the other -- for any length on the ruler, you can compare the two measuring systems' representation for that specific length. To see, set the effect time format to "29.97 FPS DF" and leave the snap-to resolution at milliseconds.  Then move the playhead to exactly 1 minute in real world time using the menu item, "Show > Goto time" and typing just "1m" into the input field.  The shorthand "1m" or "1h" or any number of seconds with decimal point always indicates real world time, whereas the "00:01:00;00" format would indicate the one minute time stamp of 29.97 FPS DF timecode -- not the same as one minute in real world time.   Figure 3 – One minute in real world time corresponds to "00:00:59;28" in 29.97 FPS DF plus 7 milliseconds.   Figure 3 shows the playhead at one minute in real world time, and simultaneously displays "00:00:59;28+07ms" in the 29.97 FPS DF effect time format.  As you can see, the timecode representation hasn't yet reached frame "00:00:59;29" and has one more frame to go after that to reach the next minute.  Since frames are about 33ms long, it is about 33 - 7 + 33 = 59ms behind real world time. At the one minute mark, however, the drop frame counting system catches up by skipping two frames, amounting to 2 * 33 = 66ms.  Set the snap-to resolution to 29.97 FPS, and drag the playhead to the right.  Observe as you move the playhead from frame to frame that the frame numbers count: "00:00:59;28", then "00:00:59;29" and then...   Figure 4 – The DF frame after "00:00:59;29" is "00:01:00;02".  Frame numbers "00:01:00;00" and "00:01:00;01" don't exist.   Frame numbers "00:01:00;00" and "00:01:00;01" don't exist in 29.97 FPS DF, so the frame after "00:00:59;29" is "00:01:00;02".  Change the effect time format to 29.97 FPS NDF and you'll see the equivalent NDF frame number as shown in Figure 5 zoomed in.   Figure 5 – The NDF frame after "00:00:59:29" is "00:01:00:00" and it is well after the 1m mark in real world time.   The frame "00:01:00:00" in 29.97 FPS NDF is well after one minute in real world time, as you can see by the gap between the playhead and the 1m mark on the timeline in Figure 5.  The timeline illustrates why the drop frame system was necessary for 29.97 FPS frame rates.

Synchronizing events in a production controlled by other people is an agreement between the parties involved about what timecode ranges correspond to what elements of the production.  Consider a concert in which the performer will perform 10 to 15 songs.  The pyro production company, lighting company, and possibly other special effects companies may all have contributions to the production that are designed specifically for each of the songs.  The timecode agreement is a list of songs and the timecode range that each song corresponds to. The agreement typically allocates a one-hour range of timecode in a 24 hour "day" for each song, making the list simple for everyone.  At the time of the concert, the songs can be performed in any order.  At the onset of each song, the production operator will start playing the timecode range corresponding to that song, which will trigger the pyro, lights, and special effects to play along in synch with the song.   Matching the timecode range provided by others When other people control the production using timecode, you need to know what timecode ranges correspond to your part or parts of the show.  If the overall show begins at timecode 00:00:00:00, and your part of the show is at the beginning of the show, then you can design your part of the show beginning at zero on the timeline in Finale 3D and export your script normally.  When the production operator plays the timecode beginning with 00:00:00:00, your part of the show will play along with it. If your part of the show is not at the beginning, then you need to make sure your script events correspond to the correct timecode range.  Typically, timecode ranges are allocated in one hour slots of a 24 hour "day".   Say your part of the show is at the hour slot beginning at 7 hours (07:00:00:00).  It is imperative that your script events begin at 7 hours, not zero hours.  In Finale 3D you have two choices for getting your script events to begin at 7 hours instead of zero: 1) you can script your show on the timeline beginning at 7 hours, or 2) you can script your show at zero on the timeline and set the "Firing system export offset" to add 7 hours to the event times in the exported script.   Moving songs on the timeline to their timecode ranges Scripting your show beginning at whatever time range is required is your only option if you are contributing multiple parts to the production at various timecode ranges scripted in the same show file.  While it may seem disorienting to have a timeline that is 15 or 20 hours long with short, 5-minute songs at the beginnings of various hours, that's what people do. If you are told the timecode ranges for each song, you need to import all the songs.  If the song files contain their timecode on one of the channels, Finale 3D will automatically position them on the timeline according to the timecode.  If the files are just audio, you need to slide them on the timeline to the correct timecode ranges and then script the parts of your show to correspond to the music. If you are given a single concert soundtrack file containing all the songs with their independent timecode ranges, then you can just import the soundtrack file ("Music > Add song...") and Finale 3D will automatically split it up and align the sections to the timeline as shown in Figure 1.  Please see Concert soundtracks containing multiple SMPTE timecode sections for more information.   Figure 1 – A soundtrack with eight songs beginning on SMPTE hours 1-8 is eight hours long!   Finale 3D also has the function, "File > Tools > Analyze timecode in soundtrack file..." which reads the timecode of any chosen soundtrack file without importing it into your show, displays information about the timecode, and optionally saves a text log file of the timecode data in a human readable form so you can see exactly what timecode times the file contains, all of them.  See The “Analyze timecode in soundtrack file…” function for SMPTE and FSK for more information.   Scripting at zero on the timeline and adding export offsets Scripting your show at zero on the timeline and setting the "Firing system export offset" to begin at the required timecode range is an option if your show file contains only one part, and thus needs only one offset to the required timecode range.  The "Firing system export offset" field is in the "Show > Set show information..." dialog, along with another field, "Timecode export offset". If you are the one supplying a soundtrack for your part of the show with music and timecode at the correct range, then before exporting the soundtrack with the function "File > Export > Export soundtrack" it is imperative that you also set the "Timecode export offset" to the correct range, matching the "Firing system export offset".  You can verify the soundtrack file you export has the correct timecode range by using the function, "File > Tools > Show timecode statistics for song file...".

Synchronizing events to music in a production you control is essentially an automated equivalent to the manual task of "press play on the soundtrack player and press start on the firing system at exactly the same time."  The automated equivalent involves combining a timecode signal as one channel of the sound track with music as the other channel or channels of the same soundtrack, ensuring the timecode signal and the music play in perfect synchronization when the soundtrack is played.  While the music channels are routed to speakers for people to hear, the timecode channel is routed into the firing system, which is configured to fire the script events according to the times in the timecode.   Creating a soundtrack with timecode The mechanics of synchronizing events involve three resources: the script, the timecode recording, and the music recording.  All synchronization is based on the relationship between these resources. The script file contains a list of events, or triggers, at specific times.  Imagine an event as, "Trigger module 1, pin 1 at 00:04:01:00 (0 hours, 4 minutes, 1 second, 0 frames)".  The timecode is an audio signal that hardware devices like firing systems or your computer can decode into a sequence of times, represented as HH:MM:SS:FF streaming in sequentially at some frame rate.  Imagine timecode as a fast talking clock reader, barking out: "0 hours, 0 minutes, 0 seconds, 0 frames, <short pause>, 0 hours, 0 minutes, 0 seconds, 1 frame, <short pause>, 0 hours, 0 minutes, 0 seconds, 2 frames, etc."  Lastly, the music is the third resource, and it is just regular digital song. Combining a timecode signal on a soundtrack in one channel with music on the other channels creates a correlation between the HH:MM:SS:FF times in the timecode with points in the music.  The timecode for the beginning of the song could begin with 00:00:00:00, or it could begin with other timecode times, such as 07:00:00:00.  Whatever the timecode range is on the soundtrack, that is the range that correlates with the music. When a firing system is configured to operate by timecode, it plays the script events whose times correspond to the timecode signal streaming in.  Some older firing systems require the script event times to match the timecode times exactly, but most firing systems today have an internal clock that locks onto the incoming stream of timecode times and progresses along with it continuously. If the timecode signal drops out, the firing system typically stops after losing the lock; if the timecode jumps discontinuously, the firing system typically recognizes the jump after a short delay and jumps along with it.  Thus, by playing the script events using its internal clock, the firing system keeps in pace with the timecode streaming in as far as speed of play, starting, stopping, and jumping, but is resilient to minor glitches in the timecode signal, and doesn't skip script events that fall in between the times in the timecode signal. Whereas the timecode signal is represented as HH:MM:SS:FF in units of frames, the script events can be represented in decimal seconds or milliseconds or any other time representation.  The representations of script events and timecode times don't need the same syntax because they all correspond to real time points on a timeline. Returning to the objective of synchronizing events to music in a production you control, you can use timecode as an automated equivalent to the manual task of "press play on the soundtrack player and press start on the firing system at exactly the same time" by 1) exporting your script from Finale 3D, 2) exporting a sound track from Finale 3D with timecode on one of the channels, 3) configuring your firing system to play by timecode, 4) routing the timecode channel from your soundtrack playing device to your firing system, using a splitter for the audio cable, and routing the other channel or channels to your speakers, and 5) playing the sound track to initiate the show!   Adding pre-roll time In real world productions, it is nice to have a delay at the beginning of the soundtrack before the music and pyro events kick in but during which the timecode is playing.  One reason for the delay is that the firing systems require a short bit of time to lock on to the incoming timecode signal.  If your show began with an event at time 00:00:00:00, the firing system might skip it if it hasn't locked on to timecode signal yet.  Another reason for the delay is that it gives you a chance to confirm that the timecode signal is correctly routed to the firing system, and that the firing system is properly configured to receive it. Most firing systems will display the timecode times as they are being received.  If you start playing the soundtrack and don't see the timecode times displayed on the firing system, you know something is wrong.  Having a delay in the soundtrack before the music and events kick in gives you a chance to scramble and fix the problem without delaying the show. How long a delay should you have?  10 seconds, 30 seconds, a minute, or even 10 minutes are common practice.  Bear in mind that if the show is set to begin at 9pm and you have a one minute delay, you need to start playing the sound track at exactly 8:59pm. In Finale 3D, you can add a delay by unlocking the song file ("Music > Lock songs on timeline") and dragging its dotted line on the timeline to right, moving the song to start at the appropriate delay.   Add the same delay to the events to keep them in synch with the song.  Press control-A to select all the events, then do "Script > Time adjustments > Shift times" to move them over.  When you export the soundtrack with "File > Export > Export soundtrack...", the exported timecode will begin at zero without the music, and later, after the delay, the music will begin.  The event times in the exported script will include the proper delay because they are at the proper positions on the timeline in coordination with the music. It is not necessary to set the "Firing system export offset" or "Timecode export offset" to add the delay when you've added the delay by shifting everything on the timeline.  The offsets are used for delays in other timecode workflows described in Synchronizing events to music in a production controlled by others; not for the delay at the beginning of a show controlled by you.   Adjusting for latency Inherently every firing system or timecode decoding device has internal latency for processing timecode streaming into it.  Decoding hardware includes algorithms to compensate, or even overcompensate, for the latency.  Thus even if the timecode in the exported soundtrack and the music in the exported soundtrack correspond exactly to the times of the pyro events in the exported script, the pyro events may be a short bit late or early in reality, in comparison to the music. To adjust for this latency, Finale 3D has an optional field in the "Show > Set show information..." dialog called "Firing system export offset".  This field is also used for some timecode workflows described in Synchronizing events to music in a production controlled by others, but for shows controlled by you this field is used exclusively for making small adjustments, positive of negative, to script times in order to make them align with the music in reality, taking into consideration all the latencies in all aspects of the firing system and audio systems. The best way to determine the firing system export offset is to run a test on your actual equipment with an LED or e-match on a firing system pin corresponding to a recognizable point in the music.  Start the soundtrack playing a minimum of a few seconds before that point in the music, to give the firing system a chance to lock onto the timecode signal and settle in, and observe if the LED or e-match fires exactly on time or a little early or late.  Choose a firing system export offset to provide the right degree of compensation.  

When you export a firing system script from Finale 3D, you produce a script file that contains a list of events, or triggers, at specific times.  Timecode provides a mechanism for synchronizing these events to music in a production you control yourself, or to music or other elements of a production controlled by other people. Synchronizing events to music in a production you control yourself is essentially just an automated equivalent to the manual task of "press play on the soundtrack player and press start on the firing system at exactly the same time."  The automated equivalent involves combining a timecode signal as one channel of the sound track with music as the other channel or channels of the same soundtrack, ensuring the timecode signal and the music play in perfect synchronization when the soundtrack is played.  While the music channels are routed to speakers for people to hear, the timecode channel is routed into the firing system, which is configured to fire the script events according to the times in the timecode.  The details and specific instructions for this process are described in Synchronizing events to music in a production you control. Synchronizing events to music or other elements of a production controlled by other people is essentially an agreement between the parties involved in a production about what timecode ranges correspond to what elements of a production.  Consider a concert in which the performer will perform 10 to 15 songs.  The pyro production company, lighting company, and possibly other special effects companies may all have contributions to the production that are designed specifically for each of the songs.  The timecode agreement is simply a list of songs and the timecode range that each song corresponds to.  The agreement typically allocates a one-hour range of timecode in a 24 hour "day" for each song, making the list very simple for everyone.  At the time of the concert, the songs can be performed in any order.  At the onset of each song, the production operator will start playing the timecode range corresponding to that song, which will trigger the pyro, lights, and special effects to play along in synch with the song.  The details and specific instructions for this process are described in Synchronizing events to music in a production controlled by others.

Most of the table editing features in Finale 3D are modelled after Excel.  Copy/paste and the "fill handle" are no exception.  Copy/paste applies to cells, or rectangular selections of cells, or rows, or selection sets of rows.  The "fill handle" is the small black dot in the lower right corner of a selected cell that provides a user interface to "fill down" with a cell value or a continuing pattern.   Selecting cells and rows Clicking on an unselected cell may select the entire row, or just the cell, depending on the user settings: File > User settings > Set click action for effects window File > User settings > Set click action for other windows By default, the click action for the effects window selects an entire row; whereas the click action for other windows selects only the clicked-on cell.  If the click action selects a cell, you can always select a row instead by clicking on the row number in the left-most column.  If the click action selects a row, you can always select and focus a cell by double-clicking on the cell. When a cell or row is selected, the arrow keys on the keyboard will move the selection.  Hold shift and press the arrow keys to extend the selection, growing it from a single cell or row to a rectangle of cells or a range of rows.  Whereas cell selection sets are restricted to a rectangular grid of cells, row selection sets can include any subset of rows, not just a contiguous range of rows.  To select multiple rows by clicking, hold the control key and click on a row to toggle it selected or unselected.  To select a rectangular range of cells or a contiguous range of rows by clicking, select the first cell or row, and then click on another cell or row while holding the shift key to select the range between them.   The copy buffer Control-C and control-V are the usual hot keys for copy/paste in the tables.  Equivalently, you can right click a row or cell and choose "Copy" or "Paste" from the context menu.  The contents of a copy operation are stored in the system clipboard, as text, making it possible to copy/paste between applications and making it possible to examine the contents of the copy buffer simply by pasting it into Notepad or any text editor. Copied cells are represented in the copy buffer straight forwardly as the editable cell text with tab and newline delimiters separating the cells.  In some cases, the editable cell text may be different from the unfocused cell text shown in the table, which may have fewer digits after the decimal point, for example, to make the table more readable.  The editable cell text always has the maximal resolution. Copied rows are also represented in the copy buffer, but in a more complex manner that depends on which table the rows are copied from.  To facilitate copy/paste between shows, or between applications, the copy buffer for rows contains the rows' explicit data and any rows from other tables that the copied rows depends on.  For example, copying a row in the script representing an event must include the row from the effects window defining the effect used in the event and the row from the positions window defining the position at which the event is located.  The representation of all this information in the copy buffer is human readable text, but it is not as straight forward as copied cells.  The details of the copy buffer are described in Copy/paste.   Copy/pasting over cells or rows If you want to fill an entire column with the value from one cell, select the cell, then copy it with control-C or using the right-click context menu, then right-click the column header and choose "Select this column", then paste with control-V or using the right-click context menu.  The copied value is pasted over all the selected cells. You can also paste a single cell value over any rectangular range of selected cells in a similar manner. Pasting rows is different.  Unlike cells, pasting rows adds the copied rows without removing any rows that are selected at the time of pasting.  Depending on the type of table, the pasted rows may be modified as appropriate.  For example, pasted events are pasted at the time of the playhead (modifying the times of the rows from the copy buffer).  Pasted positions or effects are another example.  Since the positions and effects tables require that every row has a unique name or part number, the pasted rows will have their names or part numbers modified to make them unique.   The fill handle The fill handle is the dot in the lower right corner of a selected cell, or of the bottom selected cell if a vertical column of cells is selected.  If you click on the fill handle and drag down, you will fill the dragged-over cells with the value from the selected cell or with values continuing a pattern defined by the selected cells, such an increasing sequence of numbers .   Table 1 – What the fill handle does, depending on the selected cells Contents of selected cells Number of cells selected Modifiers keys held Cells filled with Example Integers 1 Incrementing by 1 1 --> 1, 2, 3, 4... Integers 1 Control Same numbers 1 --> 1, 1, 1, 1... Integers 2 Incrementing numbers by delta 1, 3 --> 1, 3, 5, 7... Integers 2 Control Repeating pattern 1, 3 --> 1, 3, 1, 3... Integers 3 or more Control or none Repeating pattern 1, 3, 10 --> 1, 3, 10, 1, 3, 10... Strings ending in integers 1 Incrementing numbers Pos-01 --> Pos-01, Pos-02, Pos-03, ... Strings ending in integers 1 Control Same string Pos-01 --> Pos-01, Pos-01, Pos-01, ... Strings ending in integers 2 Incrementing numbers by delta Pos-01, Pos-03 --> Pos-01, Pos-03, Pos-05, ... Strings ending in integers 2 Control Repeating pattern Pos-01, Pos-03 --> Pos-01, Pos-03, Pos-01, ... Strings ending in integers 3 or more Control or none Repeating pattern Pos-01, Pos-03, Pos-10 --> Pos-01, Pos-03, Pos-10, Pos-01, ... Time 2 Times incrementing by delta 00:05.10, 00:05.20 --> 00:05.10, 00:05.20, 00:05.30, ... Time 2 Control Repeating pattern 00:05.10, 00:05.20 --> 00:05.10, 00:05.20, 00:05.10, ... Floating point number 2 Incrementing by delta 2.5, 3.1 --> 2.5, 3.1, 3.7, ... Floating point number 2 Control Repeating pattern 2.5, 3.1 --> 2.5, 3.1, 2.5, ... Coordinates or angles with three components 2 Incrementing by delta for each component (0, 30, 30), (0, 40, 30) --> (0, 30, 30), (0, 40, 30), (0, 50, 30), ... Coordinates or angles with three components 2 Control or none Repeating pattern (0, 30, 30), (0, 40, 30) --> (0, 30, 30), (0, 40, 30), (0, 50, 30), ... Anything else Anything else Control or none Repeating pattern Apple, Banana --> Apple, Banana, Apple, Banana, ...   Loosely speaking, if you select one cell containing an integer or string ending in an integer and drag down its fill handle, you'll get a sequence of incrementing numbers.  If you hold control while dragging, you'll fill with a copy of the original cell. If you select two cells containing some form of numerical delta or string ending in an integer and drag down the fill handle, you'll get a stepping sequence defined by the delta between the initial two selected cells.  If you hold control while dragging, you'll fill with a copy of the original cell. In all other circumstances, you'll get a repeating pattern defined by the initially selected cell or cells.

The FireOne CSV format is an interchange format defined by FireOne to facilitate compatibility with external software like Finale 3D and to expose the "Scripted DMX" capabilities of the new (2023) FireOne modules.  If you want to design FireOne Scripted DMX in Finale 3D, you need to export your shows in the FireOne CSV format instead of the FIR or SEM file formats.  Descriptions of the FIR and SEM formats are here. To create and export a CSV script for the FireOne firing system, please follow these steps: Design the show. If you are creating a semi-automatic show (SEM file), then select the ranges of the effects on the timeline corresponding to triggered sequences and assign them a track number by right clicking on the selected group and doing "Edit properties..." from the context menu. Address the show ("Addressing > Address show"). Export the script ("File > Export > Export firing scripts"). Choose "FireOne CSV (CSV)" from the "Script Type" field on the export dialog. Step 3 creates the script file, which is a comma separated text file.  The file format details are described in this section. Figure 1 – FireOne IFMx-32Q module with Scripted DMX capability   Table 1 – File format and encoding File format Extension Text encoding Field delimiter End-of-line Text .CSV UTF-8, UTF-16, or ASCII Comma CRLF CSV files are text files that you can open in a text editor or in Excel to inspect.  For your convenience, Finale 3D has a function, “File > Tools > Open firing system script as generic table” which opens the CSV file as a generic table for you to view or copy/paste from if you have need.   Table 2 – Special characteristics Special characteristics Description Time representation All times are represented as milliseconds, but rounded to the nearest hundredth in keeping with FireOne module time resolution. Sort order of rows Rows are sorted ascending by event time.  Since the Event field can be set to any number according to the Track field in Finale 3D, the ascending event time sort order does not imply that the Event fields are increasing in the "Track number from Finale" export option; the Event fields will be increasing, starting with 1, for the "Sequence of tracks and launch times" export option. What rows represent Each row represents a unique module-pin-eventTime combination, and contains all the information in the script file that is associated with that module-pin-eventTime combination (the pin number in the Cue field), or a DMX command (the Cue field being blank). Semi-automatic firing Unlike FIR and SEM files, which are single-trigger shows and semi-automatic shows according to the file type, FireOne CSV files can represent single-trigger shows or semi-automatic shows, based on the use of the Event field.  The FireOne CSV exporter provides three export options as described in Table 3. Using only 30 pins In the addressing dialog and the position properties dialog, you can choose the "FireOne Module, 30 Pins" instead of the standard "FireOne Module" if you want to leave the last two pins unused. You can also create a custom module in the "Addressing > Addressing settings" menu with an arbitrary maximum number of used pins. Multi-hit pins FireOne hardware, and the FireOne CSV file format, and Finale 3D all support multi-hit pins.  Non-pyro effects like flames and relays can be triggered multiple times on the same module-pin. The standard pyro addressing functions in Finale 3D assign pins sequentially, so it may be easiest to address multi-hit pins in Finale 3D by editing the script table by hand and then locking the edited rows so the show can be re-addressed for pyro without affecting them. Slats While FireOne modules all have 32 pins, you may have hardware to divide the pins up into slats, such as four slats of 8 pins each, for the purpose of igniting effects at multiple launch positions without all the ematches extending all the way to the module.  When using slats it is essential that the pin numbers used for effects at a position correspond only to the slats at that position. Finale 3D’s addressing functions support addressing constraints based on slats to allow slats from the same module to be located at different positions. Although FireOne module/pin addresses don’t provide any indication of slats (each module’s pins are 1-32 no matter how you might partition them into slats), you can configure the modules in Finale 3D as having “virtual slats” in order to make use of the slat-based addressing constraints. Virtual slats allow you to partition the channels of a module into separate slats for which you can assign addressing constraints to guarantee good pin assignments for your physical layout. For example, suppose you have one module with 32 pins that are distributed out to four launch positions on four physical “slats” or “rails” with 8 pins each. It would be important to have the addressing constraint that each slat is restricted to a single launch position, for otherwise you might have wires running from position to position. To partition the pins into virtual slats, create a custom FireOne module with a rail address template like #99-D-#8 to split the 32 pin modules into four 8-pin slats, A, B, C, D. Because these are virtual slats, even though their addresses appear like “2-B” and “3” for module 2, slat B, pin 3 (of slat B), the addresses are converted automatically in the exported FIR or SEM script the contiguous 32-pin range of the module. The virtual slat address “2-B” and “3” convert to module 2, pin 11 (pins 1-8 correspond to slat A, so the third pin in slat B is pin 11). When you export a firing script for FireOne, Finale 3D presents an "Export Options" dialog with the option to export a FIR file or SEM file or CSV file, and options that are enabled for the CSV file choice for the Event field, as shown in Table 3. Table 3 – Export options Option name Description Script Type Choose Standard Script (FIR), or Semi-Automatic Script (SEM), or FireOne CSV (CSV) Event name field contains "The value 0 always"; or "Track number from Finale" or "Sequence of tracks and launch times"   The FireOne CSV format has an Event Name field for semi-automatic shows.  Finale 3D's export dialog has an "Event name field contains" selector with three options (enabled only for the FireOne CSV file format option): The value 0 always Track number from Finale Sequence of tracks and launch times If you are exporting a script for a single trigger show, then select the first option.  If you are exporting a  script for a semi-automatic show, choose one of the other two options.  The "Track number from Finale" option fills the Event Name field with the integer value of the Track field string.  If you use this option, please ensure that all events in the show have an integer value in their Track field (unhide the Track field in the script table window to be sure).   The integer values correspond to the FireOne events that trigger the sections of the show. The "Sequence of tracks and launch times" option fills the Event Name field with a sequence of non-decreasing integers beginning with one.  The sequence advances at each row with a different Track value from the previous row, and at each row that has a blank Track field and an Event Time that is different from the previous row's Event Time.  The purpose of this option is to make it easy to script a semi-automatic show that primarily groups each unique event time as a trigger, with the option for the user to select a range of events at different event times and group them together as a single-trigger unit by assigning them the same Track.  With this option, the Track values can be anything; they do not need to be in order and they do not need to be integers; they are strictly a label that identifies a group of events to be treated as a unit with with a single trigger.  The Track values are not themselves present in the exported script. Table 4 – Specifications of CSV script fields Field name Description Row ID Row number, starting with 1 Launch Time Event time in milliseconds, rounded to nearest hundredth of a second Delay Prefire time (difference between Launch Time and Effect Time) in milliseconds, rounded to nearest hundredth of a second Event 0 or an integer from 1-999 (see export options, above) Module Module address number, from 1-99; or the DMX Universe for DMX commands.  The module number for FireOne modules is the DMX Universe of the fixture position, which you can set by right clicking the position and doing "Edit position properties" or "Configure as DMX fixture".  The DMX Universe of a fixture position gets copied into the "Rail Address" field of the script table when addressing the show. Cue Pin address number, from 1-32; or blank for DMX commands. Quantity Number of devices Product ID Part number, limited to 12 characters. DMX Channel 1-512, or blank for non-DMX row DMX Value 0-255, or blank for non-DMX row DMX Duration Integer milliseconds, or o for "Hold forever", or blank for non-DMX row DMX Rate Integer tenths of a second duration (values 0-255 for 0-25.5 seconds) over which to ramp the old DMX channel value to the new value, at which time it will then be held for an additional duration as specified by the DMX Duration field; or 0 for immediate; or blank for non-DMX rows.  As of 4/15/23 Finale 3D always writes 0 to this field for DMX rows, as Finale 3D's DMX fixture implementations use the fixture's motor speed to implement ramps instead of firing system capabilities.  For users who want to manually employ the DMX Rate field for ramps or fades of lighting parameters or moving head angle values, Finale 3D provides options to write the relevant timing information to the Comment field, which users can copy into the DMX Rate field by manually or programmatically modifying the file. Description Effect description, limited to 80 characters; or for DMX commands, the effect description annotated with the DMX channel offset from the base channel of the fixture and the meaning of the channel, such as for example the "(+2)" and "Ignition" in the description output, "Showven Circle Flamer Program -90° Short // Ignition (+2)" Comment The Notes field from the script table in Finale 3D, limited to 60 characters.  The Notes field in Finale 3D can contain comment variables in the form "@variableName" that are expanded in the output script CSV into DMX timing values that users may find useful for their own DMX parameter manipulation, such as using the DMX Rate field.  The three comment variables are @nominalDurationMs, @nominalSetupMs, and @effectiveSetupMs, whose values follow the definitions of "Nominal Duration" and "Nominal Setup Time" and "Effective Setup Time" in Programmer documentation: The DMX Patch field.  If the duration of an event is longer than the FireOne CSV file format can represent (25.5 seconds), Finale 3D will split up the associated DMX commands into multiple DMX commands back to back, and only the first of the commands for each channel will have a nominal duration in the exported FireOne CSV. Priority The lockout/hazard field from Finale 3D as an integer, limited to the range 1-16.  The default value is 1 for anything undefined or outside that range. Position Position name, limited to 10 characters An example CSV script file export is shown in Figure 2.  The DMX commands beginning with row 5 are all from the same event in Finale 3D.  They set multiple channels of a Showven Circle Flamer fixture to the values that trigger pre-defined macro "Program" for a short flame burst at -90 degrees.  The DMX Channel Base for the fixture is 50, and the offsets of the channels for the DMX commands are +1, +2, +3 and +4, as you can see in the Description field.  The DMX Channel numbers are thus 51, 52, 53, and 54. Row ID,Launch Time,Delay,Event,Module,Cue,Quantity,Product ID,DMX Channel,DMX Value,DMX Duration,DMX Rate,Description,Comment,Priority,Position 1,2760,2240,0,1,1,2,G2SH1001,,,,,White Chrysanthemum,,1,P-01 2,3250,2240,0,1,2,2,G2SH1001,,,,,(2) White Chrysanthemum ...,,1,P-01 3,3740,2240,0,1,3,2,G2SH1001,,,,,(2) White Chrysanthemum ...,,1,P-01 4,4240,2240,0,1,4,2,G2SH1001,,,,,(2) White Chrysanthemum ...,,1,P-01 5,5000,0,0,11,,0,SHV1002,51,0,,0,SVCFLM [0102] Program -90° Short // Speed (+1),,1,P-04 6,5000,0,0,11,,0,SHV1002,52,255,190,0,SVCFLM [0102] Program -90° Short // Ignition (+2),,1,P-04 7,5000,0,0,11,,0,SHV1002,53,0,,0,SVCFLM [0102] Program -90° Short // Open Time (+3),,1,P-04 8,5000,0,0,11,,0,SHV1002,54,7,,0,SVCFLM [0102] Program -90° Short // Macro (+4),,1,P-04 Figure 2 – Example FireOne CSV script with pyro and DMX rows   Table 6 – Downloadable files Download link Explanation FireOne CSV file format CSV format specifications from FireOne

Site layouts for shows that are miles across generally don't fit on a single page with a sufficient level of detail to see what is going on, so a site layout diagram strategy for large shows is to create multiple diagrams -- an overview diagram that groups the positions in a sensible way, plus detail diagrams that focus on the individual groups.   Overview diagram Figure 1 is an example overview site layout diagram for a show that is two miles across.  As you can see in this diagram, the positions for this show happen to be organized in three groups: North, South, and East.  It would thus make sense to create three detail diagrams to go along with the overview diagram.   Figure 1 – Overview diagram with groups of positions   Several things to notice about this overview diagram are, The positions don't have labels The positions are color coded by group The size of the position icons themselves is not to scale The color coding of positions is possible with the "Set position colors" context menu item accessed by right-clicking the positions in the rack layout view.  If clicking on the positions one by one is too tedious, you can copy/paste the colors in the positions table window.  The chosen color for a position is stored in the position's "Diagram Data" property, which you can copy from one position to all the others in the same group. Turning off the position labels, and adjusting the size of the position icons are customizations in the site layout diagram blueprint.  You'll want different choices for the overview diagram and the detail diagrams, so you'll end up creating one blueprint per diagram.  From the blue gear menu in the upper right of the rack layout view, choose "Create or edit diagram template" and edit the "site_layout_diagram".  Make your changes and save it under a different name for each blueprint you create.   Detail diagrams Each detail diagram shows a subset of the positions.  Figure 2 is a good example, which you can recognize is the North group of positions from the overview. Detail diagrams may be oriented differently from the overview diagram.  Both the orientation and the filter that specifies the subset of positions that the detail diagram consists of are in the blueprint for the diagram.   Figure 2 – Detail site layout diagram for a subset of the positions   Position name filter The "Position name filter" in the site layout blueprint includes all positions if it is blank.  If it contains a string, the filter includes only the positions that have that string as a substring in the position name (case-insensitive substring search).  The positions in the example show of Figure 1 and Figure 2 have a naming scheme of N-01, N-02, etc. for the North positions, and E-01, E-02, etc. for the East positions, and similarly for the South.  Thus the position name filter value of "N-" will filter to just the North positions. If you want to filter for multiple groups of positions, you can list multiple substrings in the position name filter, separated by commas.  For example, "E-,S-" would filter to the East and South positions. If the positions are already in position groups in the 3D view (the little yellow flowers on the left edge of the screen), then you can refer to those position groups in the position name filter by adding an asterisk in front of the group name.  For example, if you have a position group named "Front", then the position name filter value of "@front" would filter to just those positions.   Position label adjustments The blueprints include options for position label size and color, but you may also need to adjust the labels' coordinates to avoid overlap.  Notice in Figure 2 that the labels are all stretched to pleasing callout angles.  From the rack layout view, just click and drag the position labels to move them around. Since the rack layout view may be oriented differently from the detail diagrams, with North pointing in different directions, adjusting the position labels may require trial and error: print an initial version of the site layout diagram and look for position labels that overlap or need to be moved; then drag them around in the rack layout view and print a new version of the diagram; see if the adjustments help, and repeat until getting it right.   Scale of text The drawing tools include text boxes that are different in a few respects from traditional drawing software.  The height of the font is measured in meters or feet as opposed to points since the magnification level of the diagram can change based on the coordinates and drawings.  If the height were in points, which is constant for the page, then the size of the text would change relative to the background when the magnification level of the background changed.   Figure 3 – If "Text height" isn't large enough, change the "Scale" of the text box.   If you want to add text boxes on site diagrams covering a very large area, measured in meters or feet, the text boxes themselves have be correspondingly large, in meters or feet, or they will be too tiny to see.  The options for text height in the "Edit properties" dialog from the context menu from right clicking on the text box, shown in Figure 3, may not be large enough for the needs of a very large shoot site, or for large text titles.  If the text height isn't large enough for your needs, you can scale the entire text box up by changing the "Scale" attribute of the text box.    

Once you've created your site layout in Finale 3D by arranging your positions and importing a ground image or Google map, you can generate a site layout diagram in a matter of minutes that includes the usual information that site layouts include -- safety circles, a legend, a panel with show information, company logo, etc. Most of the content displayed in the site layout diagram comes from information you've already entered when creating the show.  The safety circles, for example, are automatically based on the caliber of the effects in your positions or on the safety distances you've manually entered into the position properties.  The company logo comes from the "Show > Set show information..." menu item that you've probably already employed.  The legend automatically contains legend items for every unique element shown in the diagram, and you can change the legend item text to whatever explanations you want.   Figure 1 – Site layout for Montreal   The example in Figure 1 shows all the elements of a site layout diagram: the information panel on the right; the legend on the bottom; the positions and safety circles; a compass heading indicating North; a scale bar; icons indicating the audience and other notable features; logo; and rulers showing important distances.   Table 1 – Where the site layout diagram information comes from Information source How the information is incorporated in the site layout diagrams "Show > Set show information..." main menu item Show name, location, company logo, default orientation of map, and other information in the information panel "Draw mode" link in upper left of site layout view Basic drawing tools to add your own circles, lines, text boxes, arrows, rulers, standard icons, and imported icon images "Window settings" link in upper left of site layout view Safety circle calculations, and turning on/off the ground image. "Site layout diagram text" link in upper left of site layout view Text and formatting of the text that goes into the information panel boxes; and text explanations for all legend items "File > User settings > Show distances in feet instead of meters" Choose whether rulers and map scale bar are in feet or meters Position properties (right click on position in 3D view or site layout view) The safety distance (for safety circles) if you want to set it manually per position Site layout diagram blueprints (from blue gear menu in upper right of site layout view, "Create or edit diagram template") Formatting template including magnification level of map, size of information panel and legend, formatting of positions, optional position filter, grid on/off, background image on/off, safety circle colors and choices, optional orientation of map if different from default Position colors (right click on position in site layout view) Colors of positions if you want to color code them in the site layout diagram   Getting started To create a site layout diagram, do the menu item, "File > Diagrams > Site layout".  Even an blank show will produce a site layout diagram that has the basic structure.  Take a look at Figure 2, which is generated from the default show that you see when you launch Finale 3D for the first time without making any changes whatsoever.   Figure 2 – Blank site layout diagram   The show name, information and optional logo in the upper right come from the menu item, "Show > Set show information...", which includes the option to import your own company logo from a PNG or JPG.  Once you have set this information, it automatically appears in any generated site layout diagrams, as shown in Figure 3.   Figure 3 – After setting show information in the menu item "Show > Set show information..."   Safety circles The site layout diagrams display safety distance circles calculated based on the effects shot from positions or based on the explicit "Safety Distance Meters" that you can type into the position properties by right clicking a position and doing "Edit position properties..." from the context menu, or by entering numbers directly into the "Safety Distance Meters" column of the Positions table window.  To choose what safety circles are displayed, and to customize the formula for the calculation of the safety circles according to the purpose of the diagram and your country's or local regulations, click on the "Window settings" link in the upper left corner of the rack layout view.   Figure 4 – Dialog from the "Window settings" link in the upper left corner of the rack layout view   The site layout diagrams can simultaneously show two kinds of safety circles, referred to as "Safety circles A" and "Safety circles B".  You can independently choose what formula each kind of safety circle displays.  Figure 4 shows that "Safety circles A" are derived from the size of the effects in the positions.  The field two down from that shows a choice for the function -- 100 ft of safety distance per inch of effect size.  The field below that indicates that the safety circles are not adjusted for wind.  The field below that specifies how the safety circles are affected by the effects' shot trajectory angles (to enable the adjustment from the effects' shot trajectory angles, you must also set the first field to "Effect safety distance + angle" instead of just "Effect safety distance").  Each of these fields has various options you can choose from. The dialog of Figure 4 also specifies that "Safety circles B" show the safety distances that you manually enter into the "Safety Distance Meters" property of the positions.  Based on purpose of the site layout diagram, you may choose one type of safety circle calculation or another.  For example, the safety circles based on effects themselves are terrific to catch any errors of misplaced large caliber shells in smaller caliber positions.  You may also want to experiment with angle adjustments to see the effect of shot trajectory angle on the expected fallout area. In the rack layout view while editing it is often useful to show two kinds of safety circles simultaneously.  Figure 5 compares two safety circle calculations: the yellow safety circles are simply 100 feet per inch of effect size.  The red safety circles are 70 feet per inch but they also take into account the trajectory angle.  The effects in this example are fanned out from side to side, and consequently the red safety circles create a hotdog-like shape that is much wider than the line of nine positions.   Figure 5 – Yellow circles: 100ft/inch; red circles: 70ft/inch adjusted for trajectory angle   Background map, magnification, and orientation The background map in the site layout diagram comes from the "Scenery > Set ground images" submenu.   As you can see by comparing the magnification levels between Figure 3 and Figure 5, the site layout diagram automatically centers and magnifies the displayed image to ensure all the elements in diagram are visible -- positions, safety circles, and drawings.  The site layout blueprint, which you can edit from from blue gear menu in the upper right of the rack layout window ("gear menu > Create or edit diagram template > site_layout_diagram"), provides additional options for centering and magnification, as well as other formatting options such as the color of positions, the size of the legend or information panel, the colors of safety circles, etc. The compass indicator in the lower right of the site layout diagram is, by default, the "Front view and site layout orientation" that you can set in the "Show > Set show information..." menu or that you can set to any angle by rotating the 3D view to your desired "look" direction, right clicking on the ground, and selecting the context menu item "Set as front view".  Figure 6 shows the site layout diagram after adding a Google map background and setting the front view to face in the direction of the audience's view.  Notice the compass indicator points North downward in the site layout diagram.   Figure 6 – If you set the front view, the site layout diagrams will rotate to match it (notice the compass arrow).   Drawings The "Draw mode" link in the upper left of the rack layout view presents a dialog of drawing tools: Lines, Circles, Rectangles, Rulers, Arrows, Icons, and Text boxes.  The dialog also includes property fields that will apply to drawn elements, such as line color, fill color, etc., as shown in Figure 7.   Figure 7 – "Draw mode" dialog accessed by clicking the link in the upper left of the rack layout view   Using the drawing tools, you can add icons for scene elements like the audience, fire extinguishers, barricades, etc.  You can draw barges and roof top areas.  Add rulers to show important distances.  Add annotations, titles, etc.  Figure 8 shows the example scene after adding a few drawings.   Figure 8 – Site layout after adding some icons and drawings   As a second example to illustrate what is possible, Figure 9 is an indoor site layout diagram that is drawn entirely with the Finale 3D drawing tools, without a background image   Figure 9 – An indoor site layout diagram drawn entirely with the Finale 3D drawing tools   The drawing tools support many of the common user interface conventions for drawing software -- control-C, control-V to copy/paste; control-click-and-drag to clone; right-click for context menu with functions like group/ungroup, bring-to-front, etc.; right-click to edit properties.  The user interface includes a few shortcuts for quickly returning to the previous draw mode, or exiting a draw mode.  A list of important but somewhat hidden user interface features is given in Table 2.   Table 2 – User interface features for drawing Action What action does Right-click on an element Brings up context menu with group/ungroup, bring-to-front, edit properties, cut, copy, paste, delete, and clone. Edit properties dialog (by right clicking) Change any of the attributes shown in the draw mode dialog, and also: rotation, scale, coordinates, and text.  The edit properties dialog is way you set the text content of a text box element. Select multiple and edit properties (by right clicking) Adjusts properties of all selected items together. Control-click-and-drag Clone the selected item or items Click on the background Exit the draw mode, returning to the "Select/move" draw mode (except not for drawing icons or text boxes, which are stamped onto the background with a single click as opposed to being drawn by clicking and dragging; you can exit these two draw modes by pressing ESC; you can choose to remain in the draw modes for multiple clicks by holding control while clicking) Double-click on the background Return to the previous draw mode (quicker than clicking the link and choosing from the dialog) Control-Z and and Shift-Control-Z Undo and redo ESC Exit draw mode Click-and-drag the corner of a selected item Resizes the item Paragraph symbols in the text entry field of the edit properties dialog The text entry field of the edit properties dialog can include multiple lines.  Press the Enter key when entering the text into the field to insert a paragraph symbol.  The paragraph symbols will split the text into multiple lines in the generated site layout diagram.   Legend and information panel You may have noticed in the progression of site layout diagrams from Figure 2 to Figure 8 that the legend at the bottom of the diagram included progressively more items, matching the elements in the scene.  The legend is automatic: every unique icon, launch position, or safety circle in the scene automatically gets a legend item.  The diagram in Figure 8 has three red fire extinguisher icons in the scene, for example, but it only has one fire extinguisher legend item. If you want to add a legend item for something that you've drawn in the scene, or even just for some notable aspect in the background image, you can add one of the "Legend pin" icons, which come in a variety of colors.  Each unique color legend pin will generate an item in the legend. To change the text of the legend items, click on the "Site layout diagram text" link in the upper left of the rack layout view.  The dialog of Figure 10 appears, with one row for each legend item, which you can edit to change the text.  If you want to delete a legend item, just set its explanation text to blank.   Figure 10 – Site layout diagram text dialog -- for changing the legend item text and adding to the information panel   This dialog also includes four rows at the top to add text boxes to the information panel on the right.  The formatting fields give you a variety of options.  The text entry fields can include multiple lines.  Press the Enter key when entering the text into the field to insert a paragraph symbol.  The paragraph symbols will split the text into multiple lines in the generated site layout diagram.   Figure 11 – The final result after changing the legend item text and adding some text to the information panel   The final result is shown in Figure 11.   Icons One of the "Draw mode" options described earlier is "Icons".   When drawing icons you can choose from the standard library of icons shown in Figure 12, or you can import your own images.   Figure 12 – The standard library of icons includes images that are commonly seen in site layouts.   Icon images can include transparency but not blending, i.e., a pixel is either fully transparent or fully opaque.  If you import a PNG image with an alpha channel, alpha values greater than or equal to 0x80 are opaque; and the others are transparent. Since creating images with alpha channels is difficult with some paint tools, Finale 3D provides a chromakey option for imported images as an alternative to the alpha channel.  The color black (#000000) or the color white (#ffffff) can be interpreted as transparent if you signal that you want it to be so by setting the four pixels in the upper left corner of the image to special values.  To make black transparent, set the 2x2 grid of pixels in the upper left corner to have RGB components of #02, #03, #00, #01, starting with the pixel at coordinates 0, 0 and progressing counter-clockwise.  To make white transparent, set the 2x2 grid of pixels in the upper left corner to have RGB components of #fd, #fc, #ff, #fe, starting with the pixel at coordinate 0, 0 and progressing counter-clockwise.  As an example, the full RGB color value of the white transparent upper left hand corner would be #fdfdfd.   Very large shoot sites Site layouts for shows that are miles across may not fit on a single page with a sufficient level of detail to see what is going on.  A strategy for large shows involving multiple site layout diagrams -- an overview diagram plus detail diagrams -- is described here.    

The U `King 30W LED Moving Head Gobo 9CH fixtures, Standard Fixture ID 087, are available from uking (SKU: B242).  The capabilities include gobos in addition to the moving head with a color wheel.   Figure 1 – U `King 30W LED Moving Head Gobo Spotlight   The fixtures have 9 and 11 channel DMX personalities.   Table 1 – DMX personality choices DMX personality ("DMX Channel Mode") Supported in Finale 3D 9CH YES 11CH NO   Instructions To design a show for U `King 30W LED Moving Head Gobo Spotlight fixtures, please follow the steps in DMX basic instructions and Light fixtures basic instructions.  If you don't already have a compatible firing system or controller capable exporting a DMX script, please refer to Supported firing systems and controllers (DMX) for the list of available hardware options.   Choosing the DMX channel ranges for fixtures Each fixture requires multiple channels, so if you are putting multiple fixtures in the same DMX Universe, you need to set the Start Address on the fixture in the real world and the corresponding DMX Channel Base on the fixture in Finale 3D to a range of channels that doesn't overlap with others.  A DMX universe has channels 1-512.  If you want to pack as many fixtures into the 512 channels of a DMX universe as you can, back-to-back ranges are the most efficient.  Table 2 shows an example for 11-channel fixtures.  Some DMX firing systems and controllers only support 50 or 100 channels, so you may not have all 512 channels to work with.   Table 2 – Example channel ranges for 9-channel fixtures in a DMX universe Fixture DMX Channel Base Channels Used 1 1 1-9 2 10 10-18 3 19 19-27 4 28 28-36 5 37 37-45 6 46 46-54 ... 56 496 496-504   Technical details The following tables show the technical specifications of the fixtures, as tested by the Finale support team.   Table 3 – DMX channels for 9CH personality DMX Channel Meaning Channel 1 (DMX Channel Base + 0) Pan Channel 2 (DMX Channel Base + 1) Tilt Channel 3 (DMX Channel Base + 2) Color (see table below) Channel 4 (DMX Channel Base + 3) Gobo (see table below) Channel 5 (DMX Channel Base + 4) Strobe Channel 6 (DMX Channel Base + 5) Dimmer Channel 7 (DMX Channel Base + 6) Motor speed (0 = max; 255 = min) Channel 8 (DMX Channel Base + 7) Model Channel 9 (DMX Channel Base + 8) Dim Modes   Moving head effects are implemented by setting the motor speed based on the "from" and "to" trajectory angles and the span of time between the "from" and "to" effects.  The speed channel value is calculated from the inverse of the degrees-per-second-for-speed-channel-value function.  Figure 2 shows the measured degrees per second for various speed channel values between 0 and 255, and the curve chosen to fit those values.   Figure 2 – Motor speed The speed values near the right edge of the chart, nearing the maximum value of 255, are so slow they don't typically arise in scripted shows, so the discrepancy between the yellow and gray lines on the far right is not that important.  A typical angle sweep of 90 degrees in a scripted show might take 0.25 seconds to 2 seconds, which equates to 360 degrees/sec to 45 degrees/sec.  Looking at the chart, the DMX Speed values from 0 to about 220 cover that range to the best of the fixture's ability (the maximum speed of this fixture is about 320 degrees/sec according to where the gray line intersects the Y-axis). To the extent the yellow line is an approximation of the measured performance, it is generally preferable to have the yellow line be below the gray line in the chart so the calculated speed values in the exported script become underestimates, causing the moving head to arrive at its destination slightly ahead of schedule instead of stopping before reaching the destination.   Table 4 – Shutter values for strobe as measured DMX Value Shutter/Strobe 0-7 Open, beam visible 8-15 Closed, beam not visible 16-127 Slow to fast   Table 5 – Color wheel values DMX Value Color 0-7 White 8-14 Red 15-21 Green 22-28 Blue 29-35 Yellow 36-42 Orange 43-49 Teal 50-56 Pink   Table 6 – Gobo patterns DMX Value Finale 3D Identifier Image 0-7 NoGobo 8-15 ThreePartRing 16-23 WideBubbleStar 24-31 Dandelion3 32-39 Shale 40-47 Bubbles 48-55 WaterWheel 56-63 Mica 64-127 Shaking gobo options 128-255 Other options   Programmer notes The color and gobo mechanisms of these fixtures require careful programming of the DMX Patches.    Programmers who are implementing effect libraries for U `King 30W LED Moving Head Gobo Spotlight fixtures may benefit from these notes: DMX Patches for one-shot "Flash" effects set the color in setup phase because the color wheel needs to move to the correct rotation in advance of the effect to be prepared.  Otherwise the audience sees the color wheel spinning to the correct color at the beginning of the effect.  The setup phase in the U `King 30W LED Moving Head Gobo Spotlight DMX Patches is a luxurious one second by default, but since it compresses against any previous effect rather than overwriting the previous effect, the luxury has no consequence. Since the fixture requires an initialize fixture effect, its fixtureDef needs to identify it for the error checking and user facing warning messages.   Table 7 – Example files and downloads Download link Explanation Moving Head DMX.pdf U `King 30W LED Moving Head Gobo Spotlight User Manual