On 3 Mar 2005 at 15:22, Mark D Lew wrote: > On Mar 2, 2005, at 11:44 PM, Johannes Gebauer wrote: > > > Just for the record, I just had to optimize many parts out of the > > score, which weren't empty at all. This was possible because the > > optimization information is stored with the absolute system, and is > > in fact manually accessable. I do not wish this to be changed, > > simply because the way it works is ideal for the work I do. > > For what it's worth, I also will occasionally choose to optimize out a > system which has music in it. I would be disappointed if this > possibility were taken away. I have no problem with some sort of > warning or changeable default that helps newbies avoid getting > confused by "disappearing" music without reducing the functionality > for everyone else.
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 (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). My point is not that the way Finale does it now is wrong or unnecessary, but that it's not the common sense way it should work. Adding in the "common sense" approach in no way implies that you'd be forced to do it that way or that you'd lose the control you currently have over optimization. My "common sense" optimization would make a best guess and then you'd be able to tweak it to fit special needs. 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. > Some on this thread seem to be discussing "optimization" as if it were > only the matter of making staves disappear in systems where they are > empty. I don't see how optimization can be separated from the matter > of specifying vertical positions for staves which vary from system to > system. . . . 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? It's not how lyrics work -- you don't have to do anything special to vertically reposition a system of lyrics. And the reason for repositioning a staff within a single non- optimized system is exactly the same as for lyrics -- to avoid collisions with other elements, most often notes that are in the ledger line stratosphere or basement, or to allow more room for things that project outside the regular vertical space of a staff. Why shouldn't systems in page view just automatically always have two handles for dragging, rather than only when a system has been optimized? > . . . 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. > Maybe some day Finale will cook up a function to look for vertical > collisions and provide vertical positions for staves accordingly, and > perhaps it will even do a consistently good job of it. Until that > happens, I don't see how "optimization" can be taken away from the > user and handed over to the software. 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. 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. My point here is not really about any specific Finale feature. It's simply that there are literally dozens of areas where the way Finale implements things is not as easy as it could be -- there are other ways to re-conceive and implement the same functionality that I believe are closer to a "common sense" point of view as to how things should work. And Sibelius seems to have a much more "common sense" approach. What Sibelius lacks is the ability to easily override Sibelius's idea of what "common sense" should be. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
