On 4 Mar 2005 at 9:50, Johannes Gebauer wrote: > 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 (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). > > In my case this has nothing to do with parts at all. The reason I need > to optimize out parts which have got music in them has to do with > doubling parts. For instance, in some situations the first and second > violins play identical parts, and for space reasons I just want to > show one of them, but the other one needs to have the music in it both > for later part extraction but also because the decision to optimize > out the second violin part is made at a later stage and needs to be > reversible.
Well, again, if layout of score and parts all happened in a single score, both having settings that could be controlled independently (instead of parts inheriting all the settings from the score, with a few exceptions), then it wouldn't be a problem. Again, I'm not advocating the removal of present functionality, just a rationalization of default behavior. As I just said in another message, in many aspects Finale seems to me to be designed more to handle the exceptions well than to do "normal" tasks easily. -- 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
