On 3 Mar 2005 at 17:28, Mark D Lew wrote: > On Mar 3, 2005, at 3:49 PM, David W. Fenton wrote:
[] > >> . . . I use this constantly, because the vertical height of a piano > >> accompaniment varies throughout the piece. A constant distance > >> from voice staff to piano-treble staff is unacceptable because I > >> don't want markings running into the lyrics on some staves, but > >> neither do I want large unnecessary gaps of white space on others. > >> Of course, this is layout-dependent, and if you later make changes > >> to the piece which alter the layout, you're going to have to redo > >> all the system optimization values. This isn't a bug in the > >> software; it's inherent in the nature of the task. > > > No, it's not. If the vertical spacing requirements were stored with > > the frames, instead of with the system, then the vertical spacing > > could flow with the measures themselves, regardless of what system > > they end up on. > > But then I'd have to define my vertical spacing requirements on a > measure-per-measure basis. . . . Do you currently have to define default vertical spacing for systems on a per-system basis? No, of course not -- there are default settings already. The default setting for the system I describe would be that the default vertical spacing for a measure would be equal to the system margins. If you reduced the vertical spacing for all the measures in a system, the system margins could then automatically contract. If you increased the vertical spacing for a selected block of measures, it would cause the system margins to expand to accommodate it. And since it was defined per measure, it would travel to any system that this measure migrated to. Say you had only one measure in a system that needed expanded vertical space. In the current situation, you adjust the vertical spacing for the system to accommodate the measure that is the extreme case. If that measure gets moved to another system, you have to start over, changing two systems. If, on the other hand, you set the vertical spacing for that one measure, if it got moved to another system, the target system would then expand accordingly, and the original system would contract back to the defaults (or to the next smallest setting in the measures in that system). > . . . I don't want to do that. . . . As I just explained above, you wouldn't have to, any more than you have to manually set system or page margins in Finale right now. > . . . How I choose to > space a system vertically is dependent on information that is specific > to the system, not the measure. For example, if an entire page is > crowded vertically, I'm going to be more inclined to tighten each > individual system than I would be otherwise. That's layout-dependent, > not frame-dependent. If a hairpin continues from m.10 to m.12 and > there are high LH notes in m.10 and low RH notes in m.12, then it's > going to need more space if m.10 and m.12 are on the same system than > it will if the hairpin is split over a system break and I can move > half to a different vertical position. That's layout-dependent, not > frame-dependent. Well, I'm not advocating eliminating system-oriented spacing adjustments -- I'm just suggesting allowing the storing of spacing requirements connected to measures, which would be much more useful to *me*. > > Optimization and vertical spacing to allow for things that project > > outside the normal staff space are two separate issues that are > > intertwined not because of any conceptual necessity, but because > > that's the way Finale implements it. > > Substitute "removing empty systems from page view" for "optimization" > and I agree. You have a very strange definition of the word. Optimization means REMOVING BLANK SYSTEMS. Read the optimization dialog box -- it says nothing about vertical spacing of staves within systems. > I suppose my recommendations along these lines would be this: > > 1. Every system has a value that specifies staves are movable (ie, use > independent vertical values) or unmovable (ie, use vertical values > from scroll view). A global setting specifies whether new systems > added will be movable or unmovable. Various means in the UI allow the > user to change the movable/unmovable value for any individual system, > or for all systems at once. > > 2. The standard default documents have all systems defined as movable. > The setting for new systems defaults to movable. That would be just like lyrics. > 3. Every system>staff has a value that specifies does or doesn't show > in the page view. Various means in the UI allow the user to change > the show/don't show value for any individual system>staff, or all > systems at once. > > 4. A global setting tells whether the Update Layout procedure should > include a check to set any empty system>staff to "don't show" and set > any non-empty system>staff to "show". By default, this setting will > be on. Well, it would be nice to allow overrides for specific systems (though I'd want it to be measure-specific). > 5. Get rid of the confusing term "optimization", a label which has > been attached to both functions which are now separate and anyway has > no meaningful connection to either. (What exactly do they think is > being made "optimal"?) The spacing on the pages -- optimized systems take up less space (if you're hiding blank staves). That seems transparently obvious to *me*, and it's the main reason I use optimization. > I believe this would satisfy both us, yes? Pretty much. But I still like the idea of vertical spacing travelling with the measure, not being permanently anchored to an absolute system position. I have to redo this kind of thing all the time, mostly because I change my mind after printing about the layout (certain pages end up being more or less crowded than I'd expected, so I end up laying things out again, and then have to completely re- start the optimization process, including vertical spacing of staves within systems). > > I see no reason why page view couldn't add top and bottom margins > > for each measure, and for measures that needed more space, you'd > > simply increase the top or bottom margin (which would in turn > > automatically expand the system's top/bottom margin). Then you > > wouldn't have to worry about re-doing your vertical spacing if your > > system layout changed. > > Hrm. I'll believe it when I see. Frankly, I don't trust Finale to do > a decent job of it. . . . I just don't see why it is conceptually any different than what we have now with the way system margins live inside page margins. > . . . Then again, I don't trust Finale to do a decent > job of horizontal spacing for any music that includes lyrics, either, > which is why I'm always tweaking them. . . . Does it do an OK job for music *without* lyrics? I don't do lyrics all that often, so defaults that got it right on the first try without lyrics would greatly speed up my work. > . . . So I suppose if Finale were to > attempt intelligent vertical spacing it would be the same idea. So > long as it remains tweakable for those of us who are unsatisfied with > the automatic, I'll be happy. Why would I *ever* suggest taking away the fine control that Finale has always offered? I'm simply trying to come up with ways that make Finale behave in a more "common sense" fashion. Finale allows the fine control, but has no common sense (defaults are usually wrong), whereas Sibelius has well-chosen common sense defaults, but then restricts to those results with inadequate ability to tweak things that aren't correct. Granted, I much prefer the Finale way, but if we're talking about the kinds of things that make Finale seem obtuse to new users (i.e., the people we need buying Finale so that Makemusic stays in business to supply new versions of Finale for those of who have been using it for 15 years), then I think optimization is one of those things that doesn't really work the way it ought to. Suggesting that it work better by default in no way implies the elimination of the control of non-default behavior. -- 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
