Ok, I took a look at your examples, thanks. I see what you're after now, basically *automatic* instead of manual handling of:
1. external ledgers (dashed ledgers work like extending the staff) 2. internal ledgers (some notes get two, some get one) You might be able to get this by writing a scheme function that would override each note, check which note/pitch it is, and if needed replace it with that same note preceded by a \once \override of the ledger line layout and/or staff line layout to get the desired output for that note. Otherwise it would just return the same note, leaving it as is. More below... [email protected] wrote > So, \theMusic is still compatible with traditional notation, except for > the tritone issue. You can see in the last bar, the interval is engraved > in the "augmented fourth" way. > I set the staff variables empty, as you told me, and did not include the > dodecaPitchNames snippet in the file. Ok, so you want your music input to also be usable with standard notation. Using variables for any needed manual overrides and blanking them out for standard notation works here, but that leaves the tritone issue. And I don't think it's possible to use your custom chromatic note names and avoid the inconsistency of tritones in \relative mode when you're outputting to a standard staff. Basically, on a traditional staff there are no tritones per se, they are all either augmented 4ths or diminished 5ths. But with your chromatic note names there is no way to differentiate between these two enharmonic intervals, so when you output to a standard staff the tritones will become either augmented 4ths or diminished 5ths, more or less arbitrarily, outside of your control. And in \relative mode that means that they will not just be different enharmonic spellings of the same interval but the notes will sometimes appear in the wrong octave, throwing off all subsequent notes. Maybe I'm missing something but I don't think there's a way out of this. There are two options: 1. preserve compatibility with the traditional staff by using the traditional note names and entering them as you would want the notes to appear on the traditional staff 2. abandon full compatibility with the traditional staff in order to be able to use the chromatic note names > So, I still didnt understand how the dodecaPitchName snippet works. Basically it changes the "default scale" so that the staff no longer represents a diatonic scale but a chromatic one, a chromatic series of pitches. This is the "ly:set-default-scale" part. Then it takes the currently active pitchnames list (which is how LilyPond correlates note names to pitches), and keeps the names, but changes the pitches so that they correspond to the pitches of the chromatic scale that is now defined as the default scale. This is the "ly:parser-set-note-names" part. So after it's done its work, when you write "cis" it puts that note on a different staff line or space from "c", because the name cis has been remapped to be a different pitch from c, within the now default chromatic scale. (Before "cis" would be the same pitch as "c" for purposes of placing it on the staff, but with a sharp alteration attached.) This is a completely different way of achieving a chromatic staff than the "staffLineLayoutFunction" approach that is used in MNP-scripts.ly and twinnote-scripts.ly. As I mentioned before: Paul Morris wrote > [The ly:set-default-scale approach] avoids the inconsistency with tritones > in \relative mode [when using custom chromatic note names]. That is the > benefit of this approach. > > The downside is that the default scale is set globally, so it affects all > staves. This means you can't have a file that includes staves based on > different scales (say if you wanted to show a traditional staff alongside > an alternative one, for comparison). Another possible downside is that > accidental signs are not shown, so you can't override them with > alternative signs (i.e. for using traditional nomenclature with an > alternative/chromatic staff[2]). > > Using the staffLineLayoutFunction approach[1] on the other hand gives you > the opposite set of benefits and downsides. > > [1] http://musicnotation.org/wiki/software-wiki/lilypond/ > [2] http://twinnote.org/learn/accidental-signs/ Basically, once you do "ly:set-default-scale" in a file it changes the scale for all staves in the file. That's why you can't have both traditional and chromatic staves in the same file using this approach. And that's why blanking out those variables in your file was not restoring the standard staff -- they were not the part that was making the staff a chromatic staff. Ok, I hope that clarifies things some more. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Feature-Request-Chromatic-note-names-tp145984p146061.html Sent from the User mailing list archive at Nabble.com. _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
