I might be one of the few people that encounters this issue.
Big files- I mean "big" like an act of a full-scale opera, around 30+ staves, and 1500-2000 bars.
The orchestral playback requires 2 instances of NotePerformer as Finale plugins.
Basically Finale works fine with these files, everything is snappy BUT.
The playback starts in 5-8 seconds, depending on computer:
8 seconds on 2021 MBP 16'' M1Pro (macos 13, latest) - that is my work computer
5 seconds on AMD Ryzen 5 7500F (win11, latest) - my son's play computer
If you work 6-9 months on a piece like that, this is unacceptable, these 5-8 seconds will be multipied by a 5-figure number.
Turning off HumanPlayback- not an option, NP needs that to play back adequately.
I have a new big work coming and there are 2 options:
1) FREE- split files to smaller chunks. Anyone knows if Score Merger will be reliable with instrument changes on staves etc.?
2) Get a fast PC (I am used to work on Mac)- like Ryzen 9 7950X.
The problem with option 2 is merely that I have been monitoring what is happening during the waiting time before playback begins (Activity monitor on mac, task manager on PC). Finale 27.3 does use multiple computing threads and thus can spread the work accross multiple processor cores. One can see that for example by using Organteq as a plugin in Finale, engaging all registers.
But while waiting for playback to start, Finale uses around 20% of resource of a single core, less than 20% actually. This means that bumping money into a powerful computer seems silly. The time will be less but the processor usage will still be inadequate. Finale on both Mac and PC is so poorly optimised- this part at least. Making users wait while using only a small fraction of available computing power does not seem a good practice.
Seems that the reasonable option is to split an act to smaller files and thus the question:
What kind of problems should I anticipate with ScoreMerger? Maybe something I should keep in mind while creating files etc.
waiting for playback to ... start
Moderators: Peter Thomsen, miker
Indeed, the delay is there whatever the playback plugin or device is. Tested.
This confirms my initial thought- Finale "renders something" before starting the playback (while waiting the plugins are not engaged/in use). When the file (probably active frames) reach beyond certain amount one starts to feel the delay. Whatever Finale does- it does so utmost ineffectively. When the playback begins then 2 instances of NotePerformer are very far from saturating the CPU. NP itself is very effective and I have never have had glitches during playback, not even with 30+ staves.
I have tried further to mingle with Play/Record Options:
Unchecking 4 dialog boxes "Play Recorded:" - no noticeable change.
Dynamics and Markings- selecting other options than Chase from Measure 1 - no noticeable change (and I could not work without chasing).
Setting Human Playback to "none"- a big change in delay, the delay time gets to about 1/3. That would make the difference but, alas, this is not an option.
I also understand that I would be one of the few people that composes full-scale operas using Finale. Knowing that it is a niche market and my issue is probably not even worth reporting to MM (I have no illusion that fixing this would be their priority).
Getting a fast computer seems just wasting money in this case because it would make probably a small difference. So I am left with ScoreMerger option as the most reasonable one.
The layout/parts phase would be a nightmare with 5-6 files. One act per file is ok. Never used ScoreMerger before and I am interested if I should do something to avoid problems before starting work.
This confirms my initial thought- Finale "renders something" before starting the playback (while waiting the plugins are not engaged/in use). When the file (probably active frames) reach beyond certain amount one starts to feel the delay. Whatever Finale does- it does so utmost ineffectively. When the playback begins then 2 instances of NotePerformer are very far from saturating the CPU. NP itself is very effective and I have never have had glitches during playback, not even with 30+ staves.
I have tried further to mingle with Play/Record Options:
Unchecking 4 dialog boxes "Play Recorded:" - no noticeable change.
Dynamics and Markings- selecting other options than Chase from Measure 1 - no noticeable change (and I could not work without chasing).
Setting Human Playback to "none"- a big change in delay, the delay time gets to about 1/3. That would make the difference but, alas, this is not an option.
I also understand that I would be one of the few people that composes full-scale operas using Finale. Knowing that it is a niche market and my issue is probably not even worth reporting to MM (I have no illusion that fixing this would be their priority).
Getting a fast computer seems just wasting money in this case because it would make probably a small difference. So I am left with ScoreMerger option as the most reasonable one.
The layout/parts phase would be a nightmare with 5-6 files. One act per file is ok. Never used ScoreMerger before and I am interested if I should do something to avoid problems before starting work.
-
motet
- Posts: 8294
- Joined: Tue Dec 06, 2016 8:33 pm
- Finale Version: 2014.5,2011,2005,27
- Operating System: Windows
When you hit the play button with Human Playback, it first goes through your file and creates a bunch of temporary data, then plays it, then removes the temporary data when playback stops. I think you're probably write that it's inefficiently programmed.
Something you might try--but I have not experience with this--is to instead use a feature of the MIDI tool, Apply Human Playback. I believe this will create the data and leave it (there's also a way to remove it later). Then perhaps you can turn Human Playback off in the playback options. Worth a try. I don't know how this will go with Note Performer, though.
Something you might try--but I have not experience with this--is to instead use a feature of the MIDI tool, Apply Human Playback. I believe this will create the data and leave it (there's also a way to remove it later). Then perhaps you can turn Human Playback off in the playback options. Worth a try. I don't know how this will go with Note Performer, though.
Thank you for your answer.
What I am doing here is composing directly into Finale and playing back sections very often. I have worked on the field with Finale more than 30 years and of course I am aware about the differences between computer playback and the reality from the orchestral pit.
Sadly "apply Midi playback" method won't work in my case. I need to play back the score sections on-the-fly very often after additions/changes to the score. Even with macros programmed and conveniently assigned to a StreamDeck keys I would lose time plus have an extra operation to do.
So I guess still the [smaller files > score merger] is the best option.
All major operations with big scores are a bit scary because in 50-60 thousand frames- if something has gone wrong, one might not notice it.
But there is also a good side- if one spends 3/4 of a year working on the score then one *should* know how the playback sounds. After merging sections into one huge file, I must simply check the playback. There are always originals plus incremental backups on different drives and clouds to return to correct material, if needed.
What I am doing here is composing directly into Finale and playing back sections very often. I have worked on the field with Finale more than 30 years and of course I am aware about the differences between computer playback and the reality from the orchestral pit.
Sadly "apply Midi playback" method won't work in my case. I need to play back the score sections on-the-fly very often after additions/changes to the score. Even with macros programmed and conveniently assigned to a StreamDeck keys I would lose time plus have an extra operation to do.
So I guess still the [smaller files > score merger] is the best option.
All major operations with big scores are a bit scary because in 50-60 thousand frames- if something has gone wrong, one might not notice it.
But there is also a good side- if one spends 3/4 of a year working on the score then one *should* know how the playback sounds. After merging sections into one huge file, I must simply check the playback. There are always originals plus incremental backups on different drives and clouds to return to correct material, if needed.
-
motet
- Posts: 8294
- Joined: Tue Dec 06, 2016 8:33 pm
- Finale Version: 2014.5,2011,2005,27
- Operating System: Windows
Unless they've changed something, Finale's frame limit is still 32,767 frames, so be aware of that. (A frame being a non-empty measure in one layer on one staff.) If you compose your opera in a few different files and then try to merge them and find that limit exceeded, you'll be in trouble. Of course, not every instrument plays in every bar, so maybe that's not a worry.
If it is, though, I think you'd be forced to break your opera at a point where you wouldn't mind beginning a new page in score and parts and leave the two pieces separate. Forcing such a page break in the score is of course not a big deal, but may be in the parts. In which case maybe you'd have to break the file vertically, into winds and strings, say, then merge those broken pieces horizontally into separate files for wind parts and string parts.
When they converted Finale to a 64-bit application, that was a golden opportunity to get rid of the frame limit (or make it 2^63 rather than 2^15). Alas, they didn't, unless they've done so recently.
If it is, though, I think you'd be forced to break your opera at a point where you wouldn't mind beginning a new page in score and parts and leave the two pieces separate. Forcing such a page break in the score is of course not a big deal, but may be in the parts. In which case maybe you'd have to break the file vertically, into winds and strings, say, then merge those broken pieces horizontally into separate files for wind parts and string parts.
When they converted Finale to a 64-bit application, that was a golden opportunity to get rid of the frame limit (or make it 2^63 rather than 2^15). Alas, they didn't, unless they've done so recently.
Thanks for the 32767 active frames reminder. It is the safest to assume that the limit is still there, I might ask about 27.3.
I wonder- if one bar in one stave has 2 active layers in it, does it count for 2 frames? As I understand- it does.
To break a big file is possible if there is a gap between scenes for example. That is of course dictated by musical structure. The tedious issue will be with page numbering in many parts- different offsets, showing/hiding/relocating the page numbers based on offset. Did that last time in 2019. Not fun. But yes, probably have to go for it again.
For me the biggest change was when Finale was released as Apple Silicon native. It was 27.3 or 27.2- I do not remember any more. From that point the app started to use multiple threads (also Intel version). My understanding is that with multiple threads the OS has a chance to spread the workload to different processor cores. Somehow I have a feeling that HumanPlayback pre-playback scan is done in a single thread. When no plugins are loaded, 27.3 thread count is around 20 +-. Start loading plugin instances for playback and the thread count jumps up.
I wonder- if one bar in one stave has 2 active layers in it, does it count for 2 frames? As I understand- it does.
To break a big file is possible if there is a gap between scenes for example. That is of course dictated by musical structure. The tedious issue will be with page numbering in many parts- different offsets, showing/hiding/relocating the page numbers based on offset. Did that last time in 2019. Not fun. But yes, probably have to go for it again.
For me the biggest change was when Finale was released as Apple Silicon native. It was 27.3 or 27.2- I do not remember any more. From that point the app started to use multiple threads (also Intel version). My understanding is that with multiple threads the OS has a chance to spread the workload to different processor cores. Somehow I have a feeling that HumanPlayback pre-playback scan is done in a single thread. When no plugins are loaded, 27.3 thread count is around 20 +-. Start loading plugin instances for playback and the thread count jumps up.
-
motet
- Posts: 8294
- Joined: Tue Dec 06, 2016 8:33 pm
- Finale Version: 2014.5,2011,2005,27
- Operating System: Windows
A simple experiment suggests that is indeed the case. It looks like there's also a minimum of one frame per "stack" measure--that is, a G.P. for 32 staves will consume one frame.
I also mainly work with opera and use a different file for each act. I don't create the page numbers in Finale--as you point out, that's tedious because of different starting page numbers required for each instrument. Rather, I combine the PDFs of each act for each instrument in a PDF program and create page numbers there. I have heard people suggest changing the Finale page offset just long enough to print each act-part, which, while still tedious, seems a little bit better than showing/hiding/relocating.
-
CELLOChica
- Posts: 2
- Joined: Sat Aug 20, 2022 7:22 pm
- Finale Version: Finale 27
- Operating System: Windows
I work with relatively small scores, anywhere from 2 staves to 6, less than 100 measures and I still have significant playback delays. Example, I select m. 15 on the playback bar, and the delay is still delayed. The measure counter is running through the measures until it gets to the one I chose. This is not true on all scores and I cannot find out why this happens. It can happen even when the same score had been starting immediately at the chosen measure before. Any clues??
Finale 27
Windows 10
Finale 27
Windows 10
