I wonder whether using counts is the right solution: it doesn't reflect typesetting (who ever uses !!!!! ?), nor musical meaning. It seems like a quick hack. Can't we make up something neater for the internal presentation?
Good point. Though, I don't have any ideas of a better representation. We need to be able to represent 7 different possibilities:
- Auto-accidentals - no accidentals - # - (#) - n# - (n)# - (n#)
Representing theese seven possibilities with only 2 properties (with '() meaning "auto-accidentals") seems quite effective to me. But I admit that the two counts do not reflect the musical meaning at all.
Though, I do think that they represent the notation quite closely - especially when thinking about how the auto-accidentals-algorithm works: It tries some different ways to typeset accidentals and cautionaries - and uses the one(s) that gives the highest number of accidentals/cautionaries.
Hence, if the algorithm finds out that it needs two cautionaries and one accidentals (as is the case for the cis in the good old "cisis1 | cis"-example) then the result is (n)#.
Any ideas, anyone?
probably something like ges-\editorialSharp. One could use a scheme function or a special Performer to select which accidentals to use.
Hmmm, Theese accidentals would not transpose, would they?
depends on how they are implemented/stored.
If they transpose then I don't like the name \editorialSharp. You need to look both at the main note (g) and the sript (editorialSharp) to find out that the note in question is a gis ans should be transposed as such.
The idea is that each Accidental grob prints only one #, natural or b. Then accidental-placement figures out how to align them. This makes it possible to use
natural #
in chords, and optionally place them like
natural # (natural) b natural #
Oh. How about (n#)? Wouldn't
n # (n b) n #
look rather stupid?
-Rune
_______________________________________________ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
