On 27 Sep 2002 at 13:39, Mark D. Lew wrote: > At 1:58 PM 09/27/02, David W. Fenton wrote: > > >Would it not make more sense to add a property to chord symbols that > >allows them to display when attached invisible notes, rather than > >mucking up blank notation for everyone else? > > It doesn't muck up blank notation for everyone else. > > The default for any staff is that notes AND attached items appear. As an > option, you can blank out the notes, or you can blank out the attached > items, or you can blank out both. Evidently, you want to blank out both, > and you can do so, either as an attribute for the staff throughout the > piece, or as a staff style to be applied measure by measure.
But why should I have to do *anything* to get things attached to nonvisible notes to be invisible? Isn't it more logical that the default should be that invisible notes and objects attached to them are, by default, invisible? Finale has never done it that way, and it has always been an annoyance for me. > In its templates, Coda provides pre-made staff styles which you can use. > Two of the three styles named "blank notation" entail blanking out the > notes but not the attached items, presumably because they were designed > with chord-symbols users in mind. (The one that blanks out all layers > blanks out attached items as well.) Yes, and I think blanking out the notes and leaving attached items visible is problematic for everyone who isn't using chord symbols attached to invisible notes. In my original posting on the subject of the non-invisible expressions, I described exactly the kinds of problems encountered, especially with positioning of articulations, which is caused by the automatic beam flipping when notes are found in multiple layers. > The point of the templates is to give a generic style which will satisfy as > many users as possible. . . . My argument is that more people would be satisfied by the more straightforward "if it's attached to something invisible, you have to take special action to make the attached item visible" as opposed to the current situation. > . . . Nobody expects that every user will like every > detail. Nobody expects that the collection of staff styles provided will > satisfy all of your needs, any more than the provided collection of > expressions will. If you don't like the staff style as it is defined in the > template, you can change it, or you can make a new one. The usability of a computer program is greatly affected by the choice of defaults. Many users will never change the defaults, so it's best to have logical defaults in the first place. In this case, the default behavior seems to have been chosen for two reasons: 1. to make it easy for people who use chord symbols (they need do nothing extra). 2. for backward compatibility with a feature that always worked illogically in the past. At some point the programmers made the decision that backward compatibility was better than fixing it in a fundamental way, and moved the *correct* default behavior to a user preference. I would argue that it's better, once you have the capability of supporting all requirements (visible and non-visible attachments to invisible notes), then you should change the default to the most logical method and make easy-to-use provisions for the users who will need the other method (displaying attachments to non-visible notes). Arguing otherwise is simply rationalizing the aspects of the program that never worked right in the first place. It's arguing to keep your pet workarounds for problems that shouldn't have existed in the first place. -- David W. Fenton | http://www.bway.net/~dfenton David Fenton Associates | http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
