On 5 Jun 2004 at 0:11, Christopher BJ Smith wrote: > At 7:50 PM -0400 6/04/04, David W. Fenton wrote: > >On 4 Jun 2004 at 18:55, Christopher BJ Smith wrote: > > > >> I suppose this amounts to a different philosophy about what I want > >> my notation program to do. > > > >You seem to assume a number of things: > > > >1. layout in the linked part would not be as fully adjustable as > >layout in an extracted part. > > > I didn't assume that at all (except in the case of Sibelius, where > parts inherit score layout, and possibly in the case of Igor, where I > read between the lines from the presentation on the website). > > I just think that if you are going to have to re-jig almost every > aspect of your part layout once you change something, why not just > re-extract parts again?
But that's a big *if*. Most of the changes I've found at that point is just different notes, changed bowings (in the case of string parts), and perhaps altered dynamics. If you're re-writing huge sections, then, yes, you might have to redo the layout. But that would be the case with extracted parts, so the advantage of being able to make many other kinds of much more common changes *without* having to redo the layout seems quite worth having. > >2. the implementation of such a feature would be accompanied by the > >removal of the current part extraction capability. > > Actually, we kind of have that feature already. I don't use it, and > neither does anyone else I know, possibly because it IS implemented in > a stupid fashion (or at least a not-very-useful fashion). In a score > with the Staff tool selected, click on a clef to select the staff, > then go to the Edit menu and check Special Part Extraction. In scroll > view, nothing happens, you still see the whole score. In Page view, > the staff is alone and extracted. No new file, all changes to the part > are immediately reflected in the score and vice versa (just turn off > Special Part Extraction or else go to Scroll View to see the whole > score.) PRint as you like, change staves to go to another part. I > don't see the use of this feature, for most of the reasons I have > already stated. The reason why special part extraction is useless to me is that you can't *save* the layout changes for the parts. There is absolutely no reason why there couldn't be two sets of layout information, one for score view and one for part view. Yes, of course, it would require alterations to the file format. But it would simply be another area where object-oriented thinking (with subclassing, inheritance and polymorphism) would be of great benefit (I've been arguing for that for years and years). Indeed, properly it should be implemented like stylesheets for web pages. You can change the entire look of a web page (not just colors and fonts) by changing to a different stylesheet. If Finale files stored a score layout that defined systems and page layout, and a separate part layout, and also allowed you to save individual tweaks to particular parts, it would be perfect. Yes, if you added 10 measures in the middle, it would break the existing layouts, but that's the case today, as well. > >Why is it that whenever someone proposes what are obvious changes to > >Finale that would make it much, much easier to use that so many > >people argue against the change on the grounds that it would be > >implemented in the most stupid fashion imaginable? > > I dunno, previous experience? (Lyric Tool, Ossia Tool, Midi Tool, > certain aspects of the Repeat Tool, to name a few.) I didn't use the Lyrics Tool before it's revision, so I don't know what was broken. What, specifically, are you speaking of there? As to the other tools, I don't see any changes in them -- they basically behave the way they have as long as I've used Finale. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
