If I have a system with 10 staves, but the last one hid all but 2 of them, and now add mm., it creates ones with just the 2 staves. Is there a way to change this behavior, so that I get unoptimized systems in the added mm.?
Mac High Sierra. Finale 25. (I got 26 and NotePerformer sounded terrible on it so I never used the former.)
If this query sounds trivial, I assure you this is (or would be) a workaround for a much more serious issue regarding Staff Systems. (When I deoptimize, as we old timers used to say, the top margin springs up by about 5 units. It still says .23611, but is actually 5.23611. I can only fix it by using negative values for the system top margin.)
Unhide before adding measures is the obvious solution. You've not told us much so if that won't do it, we'll need to know a lot more.
When upgrading to 26 from 25, many users had installation issues that were resolved by removing 25 completely. Again, without more information, it's impossible to know if that is your issue or not. Please take a look here and tell us what we need to know.
https://makemusic.zendesk.com/hc/en-us/community/posts/215729367-General-Discussion-House-Rules
I take it that the simplest solution, forcing Finale to create complete systems rather than optimized ones when adding mm., is not doable.
I meanwhile typed up a thorough description of my essential problem, intending to start a new post. Instead I will paste it in here. I will attach the benighted Finale file for reference and to allow any interested party to experiment.
There could be no source system for the solution you propose. If I "unhid" it, it would spring out like a Jack-in-the-box too, and the newly created mm. would all be congruent. Sigh.
My thanks to all those who want to take a crack at this issue. Finale says that the document was created in 2001, so I must have used and reused older scores over the years. This piano reduction for the chorus is made from the opera's full score, and too much work has been done on it to start over, unfortunately. (But I've learned my lesson.)
The second system of the first page shows the complete staff list. I used a percussion line in the first 3 pp. but won't need it again. The first problem I had was on p. 17. (It displays as 18, but I will limit myself to the Finale pagination.) I had optimized system 49 down to the two bottom staves, then decided I wanted a cue there. I added the A. line (staff styled to Lus, for Lusine) back in and all hell broke loose. The top margin went from .23611 to pretty much the equivalent of 5.23611 (perhaps exactly that). But the margin still read .23611. You could drag it down a smidgen, to what read as 0, but it was really 5! To finish the page, I resorted to negative numbers for the top margin value.
System 50 had already been done and was unaffected by these goings-on. It is complete except for the disused percussion line so there were no issues on Finale page 18, because I was always optimizing down. I was very surprised twice by the margin reading for the system 49 I had tortured into place. After a certain point, instead of my negative number it first said .5 (the system default of course), and now says the original .23611. Go figure.
My problem now is that the bottom system of p. 18 has only two staves, and beginning on the next p. I will need more. I added two mm. to show where things stand for me. The systems both sprang up (each now needing a page unto itself), as I described. System 57 has been "fixed" to -5.3 (although God only knows what it will read when you get it!). System 58 shows what happens if I do nothing.
The simplest solution/workaround would be if I could create new mm. after page 18 that had more than just the two staves of system 56.
Update. Apparently such workaround is not available. (I do seem to recall a time when Finale didn't behave this way. I don't mind someone's feature request being honored, but they should have made it optional.) Attaching a Finale file does not seem to be possible (didn't it used to be?). Here is the Dropbox link. Finale 25.
Update 2.
In a sense, I already have a workaround, if one much less than ideal! I can keep applying negative values to each new system's top margin. To fine tune that process I went to an independent file and added a measure to the end. It behaved normally. I tried unoptimizing the new system; again, no problem. So the issue is my corrupt file, not Preferences or a Finale bug. I had planned to do my choral folio in a single file; instead, I will create a new one from scratch beginning with the second act (of two). The independent file also had a .23611 top. I eyeballed it, and sought to reproduce the dashed top margin in my faulty file. The 5.3 I had in the file attached above was very close. I believe that the exact amount, and the one I will be using unless one of you geniuses comes to my rescue, is -5.36111. By the way, if after adjustment you try to move the top handle in System mode up or down, Jack springs up again! (Moving other handles is fine, thank goodness!) So I will have to move all my systems in Page Layout.
If I am lucky, the compiler will at some point correct the negative values to the .23611 the system seems to remember, as happened with system 49.
[This is the third time I am responding to to Adrian. The first two times it did not take.]
What do you mean by "if your score is set to optimized as its default"? If your last system is locked and you add measures then, as I said, the newly created system has the same optimization as the last one did. Do we have any control over this?
I tried your good idea of adding notes to the new system from within scroll view. But back in page view the Jack-in-the-box had indeed gone off!
You mentions "unoptimized systems" in your opening post. Optimized is the former term for "hide empty staves." If you have set your systems to hide empty staves, added staves will not appear until there are notes in them. Using Scroll View would allow one to see all the staves, and once one adds notes to them, the staves will appear (for that system) in Page View.
[Again, second attempt at submittal.]
It was your phrase "if your score is set to" that threw me off. It made me think you were talking about some kind of system or document preference. You weren't talking about the score as a whole, but rather about this particular point in it. Again, I don't feel that new systems should necessarily form with the optimization of the one directly preceding. That should be an option you could turn on and off, depending on the context. My problem was never getting this or that staff to appear. It's that if a new system had more active staves than the one preceding, its top staff would shoot up into the sky. That's still true, but I'm learning to live with it.
When someone in my position comes to this forum, it's with the hope that some arcane feature of Finale that only you experts could know about will solve whatever problem has cropped up. Or that it's all about some bug, and here is our workaround for that. But no, this is clearly a corrupt file, and I'm lucky I can keep my work so far and ultimately soldier on to the end of Act I with this folio!
Attaching a Finale file does not seem to be possible (didn't it used to be?)
Not in the eight years this forum has existed. Your Dropbox link worked fine.
But no, this is clearly a corrupt file,
I see no evidence of this. When I double-clicked, if did crash my copy of 27 but, when I opened Finale first then selected the file, it opened up with this message (not an error). Clicking on Yes opened it right up.
it's with the hope that some arcane feature of Finale...
Nothing arcane here. This score in both Scroll and Page View behaved exactly as I expected. To me, the workaround is simple. Add your measures in Scroll view where all staves are displayed, then change to Page View and use Show/Hide to optimize the layout to suit your needs—as Adrian has been trying to tell you. This is exactly the way Finale is designed to work. Per the manual:
Hiding staves
Starting in Finale 2012, Optimize Staff System was replaced with Hide Empty Staves. In published full scores, it’s customary to omit from a system any staves consisting entirely of rests, which results in a more compact and readable score. This is sometimes called "French scoring." In Finale, ...Finale/ht-hiding-staves.htm
https://usermanuals.finalemusic.com/FinaleMac/Content/Finale/ht-hiding-staves.htm?Highlight=optimize
I tried opening the file in 26 to see if it would make any difference. I got that same message you did, but decisively clicked "No," since I didn't want to lose my engraving up to that point. (As you can see in my score, I am engraving as I go along in making the arrangement.) But it didn't matter that I clicked "No." While I was in 26 I noticed an error and fixed it, and saved my work in the original file. Big mistake. Back in 25, all of my articulations (from p. 1, I mean) were awry. Fortunately, I had a copy in Dropbox I could use to get them back. So fixing everything took about 25 minutes instead of three hours!
I already told Adrian that working in Scroll View is no help. "I tried your good idea of adding notes to the new system from within Scroll View. But back in Page View the Jack-in-the-box had indeed gone off!" Any new system that has more staves than the previous one has a top margin up in the stratosphere, such that each system takes up its own p. In the case of my file, that will be the next one, as a voice cue is getting added to just the piano staves group. And, as I also already said, any subsequent system will be congruent with the new faulty one.
I don't know what Mike means when he says "exactly as expected." Does the queer behavior I have described not obtain in 27? I'll attach p. 19 (18 in Finale pagination) in a .jpg. Mike, do the staccatos in the cue mm. at the top look like these in your 26/27 conversion? Thanks to all. 
The few minutes my file spent in 26 had other consequences too. I see now that my lyrics, something which I subject to painstaking "manual adjustment," also got knocked out of place every so often. Another 20-minute restoration job is in order but, again, I luckily have the life-saving version history in Dropbox.
Please sign in to leave a comment.
12 comments
Date Votes