David, I switched to having a single document for score and parts several years ago. It requires a little more time, but I think it is worth it. To address the issues you raised:
1. Do not use "Blank notation with rests: Layer 4". This staff style can occasionally be useful for partial measures (often for measures that have a cue overlapping with a pickup note). But otherwise it isn't an ideal choice. Instead create a new staff style of Blank Notation with Rests for Layer 1. Then uncheck everything in "Other Layers: Show". In my files I name this staff style "Hide Cues". 2. For clef changes you'll need to create a separate staff style with the same transposition as the score (or lack thereof) but with a forced clef to the clef you want in the score. You then apply that as needed in the score. In my files I give them names like "Force Bass Clef" or "Force F Treble Clef" (if it were for a transposed horn staff). There are still occasional edge cases where even these two techniques aren't sufficient and you have to resort to using expressions for either rests or clefs. Often you can simply opt for a different cue. But me being me, I sometimes soldier through with expressions when there is a complicated cue I think is really important. Another way to hide clef changes in the score is with a "Hide Clefs" staff style. This is often a perfectly acceptable alternative to a forced transposition clef, if the cue is entirely contained on a single score system. There are occasionally situations where this is preferable to forced transposition clefs. (Since forced transposition clefs must be applied to full measure whereas hide clefs can be applied to a partial measure.) Christopher Smith is correct about voiced parts. They are not usable, and not just because of the problems with cues. Their inability to be edited with Special Tools is an unacceptable limitation by itself. Thus for large orchestra scores I continue to maintain two files, but with a difference. The staves that do not split into multiple parts (frequently Timpani on down) reside with the score. The parts that do split (e..g, winds and brass) reside in a separate "distributed parts" file. Each file has *only those parts* defined. That is, the score file contains a Violin I part while the distributed-parts file does not. The distributed parts file contains a Clarinet 1 part but the score file does not. Of course both files have a score since there is no avoiding that. I ignore the score in the distributed parts file, except as a means for editing multiple distributed parts at once. Finally there are occasionally situations where a cue that shows in one part can cause another part not to create a multimeaure rest as you would like. It is for this that I created the Force option in my multimeasure rest plugin. The Force option places a multimeasure rest exactly where you select, without regard to anything that might break it otherwise. (So use with caution!) Robert On Wed, Jul 25, 2018 at 7:51 AM, Christopher Smith < [email protected]> wrote: > Hi David, > > Short answer: no. > > These are all valid problems with having the same parts and score file. It > gets even worse if you ever have two instruments on the same score staff, > but separated (voiced) linked parts. Cues break completely in that case, > along with some other things. The amount of kludges involved in getting > something simple, like a clef or whole rest, different from the score and > parts is monumental. A graphic whole rest can be done with the default > whole rest hidden, but that has to be hidden manually in the score. It all > piles up. > > I think having different score file and one other file for all the parts > is by far the best solution. Frequent incremental backups are the solution > to the overwrite bug. I incrementally change the number on the filename > “Symphony 001.musx” then Symphony 002.musx” etc. > > Christopher > > > > On Jul 25, 2018, at 8:36 AM, David Froom <[email protected]> wrote: > > > > Hello all, > > I’m hoping for some wisdom from the group. > > > > I’ve been in the habit of having a score file separate from a parts file > — basically, to get the score looking great, then make a copy of it to make > parts so as not to have to deal with things that conflict. The downside is > that errors I discover in the parts aren’t fixed automatically — and I fear > having two files open, having been bitten by the “overwrite” bug! > > > > I decided, however, in my current project, to try having just one file. > > > > I am using TG Tools to create the cues. That puts the cue into layer 4 > and a forced whole rest (no matter the meter) into layer 1. Then, in the > score, I apply the staff style called “Blank notation with rests: Layer 4.” > Conveniently, it is triggered with the keyboard shortcut “Q,” so I assume > this was created for use with cues. > > > > I’ve run into two problems. One is if the cue has a different clef from > the prevailing part. So, in the staff style, I indicate that it should NOT > show the clef. That’s fine, except when, in the score, the staff style > starts at the beginning of the system. Then I lose the clef there. I can > work around this by putting in a graphic clef in the score and hiding it in > the part. OK. Is there a better solution? > > > > Problem two is something for which I can’t find a work around. In the > part, I often need to move the cue’s layer 1 whole rest, as the default > position is sometimes too high — or above the staff when I’d prefer it > below. However, this moves it in the score! I can’t seem to unlink it. > > > > Can anyone who has mastered having score and parts in one combined file > please share some tips on how to do this? Is there a better staff style? Or > a better method? > > > > Thanks in advance, > > David Froom > > _______________________________________________ > > Finale mailing list > > [email protected] > > https://lists.shsu.edu/mailman/listinfo/finale > > > > To unsubscribe from finale send a message to: > > [email protected] > > > _______________________________________________ > Finale mailing list > [email protected] > https://lists.shsu.edu/mailman/listinfo/finale > > To unsubscribe from finale send a message to: > [email protected] > _______________________________________________ Finale mailing list [email protected] https://lists.shsu.edu/mailman/listinfo/finale To unsubscribe from finale send a message to: [email protected]
