On 21 Dec 2005 at 21:51, Robert Patterson wrote: > > -----Original Message----- > > > > What aspects of layout are fixed by forking the file before you > > extract parts? > > It allows you to edit the score for extraction without affecting your > clean score. These edits are likely to be > > 1. Preprocessing (e.g., TGTools Smart Explosion). > 2. Cues. > 3. Headers (as for staff names). > 4. Miscellanous Edits. > > Item #1 generally only applies for large band and orchestra scores, > where it is necessary, e.g., to break the 4 horn parts out onto > separate staves before extracting. (In many scores, they are combined > on staves in the score to reduce the vertical footprint of each > system.) Judicious application of TGTools Smart Explosion helps reduce > the pain in this process to a surprising extent, even with quite > convoluted changes in the distribution of parts on staves from one > system to the next.
Why not extract to a part, then explode from that? > Item #2 is obvious. It is much easier to create cues before > extracting, especially with the help of tools like TGTools Add Cue > Notes. Why can't it be done in the score, and placed in, say, a layer that is not visible in the score? > Item #3 is less obvious, unless you happen to use my Copyist Helper > plugin. Then what you do is create headers with staff-name > placeholders. After extraction, the plugin can convert the > placeholders to actual staff names. This is far more flexible than the > limited features for staffname headers built into Finale's part > extraction. These added flexibilities include This one I simply don't understand. > 1. Precise placement of a header on page 1. Precise placement of a > different header on the rest of the pages. > > 2. The ability to embed the staffname inside other text. > > 3. For doubling parts, the ability to show the current instrument name > in addition to (or instead of) the staff name, e.g. "Reed 1--Soprano > Sax". > > For more info, see the Copyist Helper page at my website. Is this one such a huge problem? I understand now, though I only encounter in a very primitive form, since my requirements for parts are, apparently, substandard, in comparison to yours, but this is hardly a valid reason for completely forking the file, seems to me. > Item #4 (Miscellaneous) may include stuff like moving the titles on > page 1 (and/or global titles) to match what you want in each part. For > me, quite often, the placement of page 1 titles in the score bears > only passing resemblance to that for parts. It's a nuisance to move > them around separately in each part. Can't this be controlled by *not* setting up separate text blocks for parts and scores? I forget all the available settings, but you do have some control over which things appear in the score and which in the parts. If MM would just implement layout independence in Special Part Extraction, they'd be more than 75% of the way to having linked parts and solving these problems you've outlined, none of which seems to me to be significant enough to require such drastic action as forking your score files. All that labor has to be discarded if you end up perform any significant edits on the score after the forking. The amount of work then seems to me to be vastly more than what's minimally required to extract from an independent file. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
