Good evening! I’m not sure if this is the right thread to ask this question but…..  I’ve created some effects in Finale that I am now trying to “edit” such as change the timing.  The original “cake” that I created was longer than what it needed to be so I’m attempting to change the timing from 90s to 36s but so far I have been unsuccessful.  I go into the VDL and change the seconds but when I save the changes nothing has actually changed.   Do I just need to create a whole new cake with the new timing?   Thanks!!

Great question, and one that I know will garner different opinions from designer to designer because the preferred approach depends as much on artistic preference as it does on other factors.   For my part, I’m a firm believer in aligning single shot effect times (represented by “blips” on the timeline) with the points in the music where you want the effects to visually appear. If there is a delay between the firing system ignition and the appearance of an effect in real life, then I would account for this time as Prefire (PFT). My reasoning is that this is both the most efficient approach based on Finale 3D’s effect-time-centric scripting paradigm, and because I’ve found it yields good real-world results.   To get the best real-world results, I think there’s absolutely no substitute for testing. If you want accurate timing, you just have to know your product and your firing system. So, then the question becomes, how do you conduct a test? One way to do this is by creating a beep track, scripting single shots with 0 PFT perfectly aligned with the beeps, then shooting the show with time code just like as if it were any other pyromusical. To measure the timing, record a video that captures the single shots at launch and the audible beeps from a close-by sound system.   The logic is that since the single shots were aligned precisely with the beeps in the script, any delay between the deeps and appearance of the single shots in the video can be accurately measured. This delay is the prefire time.   If you do a test like this, you might be surprised to find that even though firing systems apply power to e-matches instantaneously, it still takes a little time for an effect to be ignited and visible above the tube. In real life, you might even find that it “feels” better if the item appears slightly early which simply means you would want to use a slightly longer prefire. In Finale 3D, there is no delay, effects appear truly instantaneously, and it doesn’t “feel” good when they appear early, that’s why any single shot prefire less than 0.5s is treated as a delay before simulation.

My question relates to pft’s of simulation vs. real world firing of single shots. Since “Prefire < 0.5 defines delay before simulation,” in the animation of a ss with a pft of 0.2, for instance, we don’t see anything happening until the effect time. I believe that most firing systems fire instantaneously, so in the real world, we are going to see the item before we see it in the sim.   My question then to those of you who may have studied this is, is it better to use a small pft for single shots and align the blip exactly where you want it, or, for a better visual idea of what one can expect to see, to set the pft to 0.0, and back up the item on the timeline?   The reason for this: in many shows I’ve designed, I wonder why some shots just don’t seem to be timed as well as I expected. They looked great in simulation but not at the show.   Thanks

Thank you very much for your reply Neil. It’s exactly what I was looking for! Have a nice day!

Hello Pyro_88670000,   Sometimes MP3 files show artifacts like this when imported into Finale 3D due to the way the files are encoded and decoded, so this probably isn’t your fault or because you did anything wrong.   Here’s a post that addresses the MP3 issues and describes how to solve them: https://finale3d.com/groups/english/forum/topic/mp3-audio-issues-popping-clicking-static-when-importing-songs-into-finale-3d/

Hello everyone,   I’m writing to you because I can’t find the solution to my problem. If it has already been asked, I apologize for not finding it. When I import a soundtrack designed with Audacity, I get white noise (what I call graying) at the beginning of my soundtrack and throughout the mix (between each track).       Do you have any idea where this might have come from?   Thank you very much! 🙂

Hi Pyro_41400000, welcome to the Finale 3D community and thanks for posting!   Be sure to head over to your My Profile page to customize your display name and profile picture.   You certainly didn’t waste any time jumping into an advanced topic with your first post! Your description along with the screenshot makes the issue perfectly clear. It doesn’t appear that you’re doing anything wrong. I did a quick test in Pro and I’m getting the same result which rules out the Hobbyist version being the culprit. I will investigate further. In the meantime, a quick solution for you is to copy and paste the contents of the Rack Type column into the Custom Script Field column (in the script window). Then, change your addressing constraint for slats from ‘Rack Type’ to ‘Custom Script Field’.

Hi Blackbat, pulling the show name from the Finale 3D show information into the fireTEK V4 script header sounds like a nice improvement. Looping in my colleague Will (who does the software development for firing systems) to get his insight.   Will, what do you think?

DrewFinale I found this information and the video helpful, but either I’m doing something wrong or the Rack Type is not functioning for Hobbyist – which I understand it is supposed to. If I assign Rack Types to my effects, The addressing does not seem to recognize it to restrict slats to each Rack Type.     Attached is a image of my addressing constraints and the script.  If I understand the constraints properly, Rows 3,4,5, & 6 should be on a different rail than Rows 1 and 2.    

The first row in the most recent v4 format of the fireTEK csv script should contain “##<show name>”, so that the name of the show being fired is displayed on the firing controller screen. When Finale3D exports a csv script file for fireTEK, rather than using the show name from the show information dialogue it appears to use the saved script file name. As the file normally has to be called “script.csv” , the first line in the script ends up being “##scriptcsv” when exported from FInale3D. I was wondering if this is by design, or whether it is a small bug in the script creation for fireTEK exports. It can be manually changed after the csv is exported, but it would be nice if it used the “show name” parameter from the show information dialogue.