On Mar 3, 2005, at 3:49 PM, David W. Fenton wrote:
My point is that simple optimization (i.e., removing blank staves from a systen) should happen automatically if you have optimization turned on for the passage of music represented on a system
If I'm understanding you correctly, you are suggesting that any system which has been optimized with "remove empty systems" checked should be marked as such (perhaps it already is; I don't know), and then subsequent layout changes should be monitored so that if music is added to a removed staff in such a system, that staff will be reinstated in the page layout. (And similarly, I assume, if all music is deleted from a non-removed staff.)
I'm not sure exactly what events would need to trigger this check. Maybe it's sufficient just to do it with any Update Layout, rather than checking every time a frame is altered by Simple, Speedy, Mass Copy, etc..
If that's what you're suggesting, I think that's a fine idea -- so long as there is some sort of override that allows me to remove a non-empty staff when I want to.
(while I understand that Johannes has a use for optimization being stored in absolute systems, I think that's a different kind of issue that comes about because of the way one is forced to create parts in Finale -- if they were all stored in the same file instead of in separate files, his issue would likely go away, since you'd have a score layout and a part layout, all stored in a single file; but that's another issue where I think Finale is confusing and less than ideal).
I don't know what Johannes's needs are, but mine have nothing to do with score vs parts. When I use optimization to remove non empty staves is in a large choral piece where the divisis change in such a way that it makes sense to display some sections with the two parts on a single staff and other sections with them on separate staves.
When I have a piece like this, it is often most convenient for me to create enough staves in score view that I have one for each part separate AND one for the parts combined. When entering the music, I have a rough idea of where it makes sense to switch from combined to separate, but I don't know exactly where the system break is going to end up. Typically, I'll have a few bars of overlap, where I enter both in score view. Then that gives me the flexibility to twiddle around with it in page view, and once I have the layout settled, I remove the unnecessary staves from each system and it all reads smoothly. There are other ways to achieve the same thing, of course, but I find that the ability to use optimization to remove a non-empty staff facilitates the process, and that's why I don't want that option removed.
And if your particular pieces had characteristics that made my "common sense" optimization turn out wrong all the time, then you could simply turn off the "common sense" optimization and do it the way Finale has always done it.
That's fine with me.
I think it's wrong of Finale to *not* separate independent vertical positioning of staves within a system from optimization. Why should you need to optimize before you are allowed to move staves vertically within a system? Where's the logic there?
OK, I think I understand now. This is just a matter of semantics. In my mind, the essence of "optimization" is the fact that an optimized system has its own definition for vertical positioning of staves and a non-optimized takes staff positioning from the scroll view default. From my view, asking why one should need to optimize in order to move staves vertically is nonsensical, since that's exactly what optimization is. The ability to add or remove staves while adding optimization is just a side effect.
No doubt this is due to the different natures of our respective work. I mess with vertical position of staves all the time, whereas I rarely have need to remove an empty staff. Indeed, when I apply optimization, I generally leave "remove empty staves" unchecked, unless I have a specific staff in mind to remove.
I actually agree with you that the two features may as well be separate. It's just that I would have worded it to say that removal of empty staves is what needs to be separated from "optimization". When I read your messages about making optimization automatic, I thought you were arguing for the computer to apply vertical position of staves automatically. That would be nifty if it could do a good job of it, but I think it's a big step MakeMusic isn't going to take any time soon. In any case, that's a separate discussion from the matter of removing empty staves from page view.
And the reason for repositioning a staff within a single non- optimized system is exactly the same as [...]
Again, to my ear this sentence is meaningless. If you're repositioning a staff, the system if optimized by definition.
Why shouldn't systems in page view just automatically always have two handles for dragging, rather than only when a system has been optimized?
In other words, have optimization turned on by default? I'd be fine with that.
. . . 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. I don't want to do that. 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.
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.
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.
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.
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"?)
I believe this would satisfy both us, yes?
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. 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. 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.
mdl
_______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
