Re: Feature Request: Chromatic note names

[Paul Morris]

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...


address@hidden 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.