On 5 Jun 2004 at 14:59, Christopher BJ Smith wrote: > Did you see my reply enumerating what I thought such a architecture > should contain? Do you see anything missing?
Yes -- I replied to your earlier messages before reading that. You described it quite well, I thought. I'd *love* to have the capabilities you described. Of course, I'd also like to have subclassing of expressions and articulations, so that you could override the behavior of individual instances, rather than having to create multiple visually indistinguishable versions of the same expression/articulation for various purposes. Also, I'd like to have the ability to define non-printing expressions without having to use the <brackets>, as with non-printing articulations. And I'd like the display of the non-printing ones to be distinct from the printing ones. My reasons for this: 1. Most of my Finale work is transcribing original manuscripts/editions, and I want to retain as much of the original in my transcription. 2. But, I also want to create editions from these. At present I add non-printing expressions/articulations for creating my MIDI performances. When it comes time to produce and edition, some of these I will convert to printed editorial suggestions, distinct in appearance from the ones in the original source. Right now all I have to do is alter the expression/articulation to have a distinct appearance and then make it printable. But in the case of articulations, it's annoying to not be able to tell onscreen which is which (it's clear with expressions). And if the subclassing I'd like were implemented, none of this would be necessary. Instead, you'd insert the expression/articulation intended, and then right click it and mark that particular instance non-printing. And maybe you'd change the definition of the way that instance affects performance (maybe add 15 to the key velocity), and perhaps you could change the font that this particular instance uses (make it 20 points instead of 24). In Finale today, I'd need to create a new expression/articulation for each case where I wanted a unique set of appearance, printing/non- printing and performance effect. This makes your file littered with multiple hard-to-distinguish definitions. I seem to remember that Finale2K4 adds the ability to annotate them and that these annotations appears in the selection dialogs. But that's a kludge to get around the base problem, that you're forced to create multiple copies of the same thing because they aren't related to each other. I just wish all of this was implemented like Word's style definitions, where a new style can be based on an old style, inheriting all of the old styles characteristics, but allowing you to override individual aspects in your new style. Yes, staff styles are a first implementation of something like this, but don't seem to be sufficiently cascaded to be useful. Were it not for blank notation, I wouldn't use any staff styles at all, myself. But I'd find it much more useful to be able to have expression/articulation definitions based on each other, or have the ability to over-ride behavior/appearance for individual instances. -- 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
