On 9 Jul 2005 at 0:08, Johannes Gebauer wrote: > David W. Fenton schrieb: > >>The cadenza example was about having more measures in the part than > >>there are in the score. > > > > Hmm. Easily handled by optimizing out the cadenza systems in the > > printed score, no? > > > > Why make it harder than that? > > > Actually I don't think this is sufficient. What if the layout doesn't > allow that? . . .
Why wouldn't the layout of the score allow it? If it's a solo instrument cadenza, and you don't want it displayed in the score, those measures can be put on their own systems and those systems optimized out. What layout would prevent that? Surely not multiple simultaneous cadenzas, since you could still optimize out the systems you don't want displayed. And if there's other music being played during the cadenza, you don't have a different number of measures in the cadenza part. > . . . This would be the half-hearted design that I fear most > with such improvements. All of these cases need to be covered without > clumsy work-arounds. Well, how would you handle this today? Would you *really* extract the part and then insert the cadenza only into the part? I certainly wouldn't! It's too easy to lose data that exists only in a part. The way I look at it, certain things are going to be too complex for dynamic parts, and in those cases, you should be able to revert to traditional extracted parts. It seems to me that trying to do everything in dynamic parts is going to be impossible, because accomodating every single one of these requirements makes it so complicated as to be insurmountable. If, on the other hand, you have an alternative method for getting these additional features that is identical to how it would have been accomplished in earlier versions of Finale, it seems to me as though you've got a big win -- dynamic parts for the vast majority of parts, and the ability to extract to an independent file for the complicated ones that dynamic parts can't really accommodate. My guess is that it's one of those 90/10% things. If getting 90% of the functionality takes 10 manhours, getting the last 10% implemented often takes 90 more manhours. As long as functionality is not removed from Finale, you'd still be able to get the job done, even if the new feature doesn't implement it. And if the design goal is getting something usable as a productivity enhancement for most situations, rather than getting a 100% complete implementation that covers all eventualities, who is going to complain? -- 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
