lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: es means ees???


From: David Kastrup
Subject: Re: es means ees???
Date: Tue, 07 Oct 2014 10:55:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Richard Shann <address@hidden> writes:

> On Tue, 2014-10-07 at 09:50 +0200, David Kastrup wrote:
>> Richard Shann <address@hidden> writes:
>> 
>> > On Tue, 2014-10-07 at 11:04 +0900, Graham Percival wrote:
>> >> On Mon, Oct 06, 2014 at 01:41:30PM +0200, David Kastrup wrote:
>> >> > Richard Shann <address@hidden> writes:
>> >> > 
>> >> > > Here, instead of ees, is written es.
>> >> > 
>> >> > I read
>> >> > 
>> >> >     In Dutch, aes is contracted to as, but both forms are accepted in
>> >> >     LilyPond. Similarly, both es and ees are accepted. This also applies
>> >> >     to aeses / ases and eeses / eses. Sometimes only these contracted
>> >> >     names are defined in the corresponding language files.
>> >> 
>> >> Yes.  In case anybody was wondering, I deliberately moved the "as"
>> >> and "es" contractions from the tutorial into the NR ages ago.  For
>> >> people unfamiliar with that notation, it's easier to remember
>> >> "letter name plus -es or -is" rather than introducing all the
>> >> contractions.
>> >
>> > That was a good idea I think. What is unfortunate is that the default
>> > includes these contractions,
>> 
>> Uh, the contractions are the _proper_ names.  The non-contractions are
>> not correct note names in any language.
>
> No more than ef is the correct note name in English for e-flat.

English has no actually computer-language suitable correct note names.
The closest would indeed be "e-flat", but as an identifier that has been
become valid only recently, and indeed I am tempted to change the "full
English notenames" to that since they are primarily used for things like

\key aflat \major

The next best thing would be a♭ for both proper and frequent entry but
that's hard to type on many keyboards.  Let alone a𝄫or similar.
However, it would be conceivable to let a note-language aware editor use
that as visualization.

>> > with hindsight it might have been better to have the default be the
>> > simplest set of names with those that wanted to use the contractions
>> > including a language specific file (e.g.  nederlands).
>> 
>> I disagree.  There is nothing to be gained from using a notename
>> language nobody uses.
>
> yes, we do it for English to save typing.

Using artificially longer regular notenames does not particularly save
typing, so that does not seem to favor aes.

>> I'd consider that bad style.  Again, the "contractions" are not
>> sloppy writing or anything.  They are the _proper_ German and Dutch
>> note names.
>
> yes, from that perspective. Well it is 10 years too late,

You underestimate LilyPond's history.  At any rate, we should be more
concerned with the next 30 years than with the past 10, and convert-ly
can pitch in quite a bit (though most notenames are short and non-unique
enough to be really bad for automatic conversions).

I just don't see a case here.

> but perhaps the sharp and flat signs would have been better, with
> things like "s" "f" "is" "es" all available via an included language
> file.

Again, you are looking at this with the perspective of an automated
writer rather than a human one.  If that was the focus of LilyPond, we
would talk to it in MusicXML.

> Most everything else is either Italian or English.

Pretty much exclusively English "unless" it is a direct musical term
you'd also use when talking about music in English.

The notenames are the main exception because English notenames suck.
It's a wonder black keys survived in Britain since it is so inconvenient
to talk about them.  On the other hand, it would probably have been
imprudent using something like -is -es as distinguishing feature in a
language that might as well be written in the Hebrew alphabet for all
the care it exerts over the accuracy of its vowels.

> But that's life in language development.

LilyPond changed a lot over time.  I just don't see a point to change
anything _here_.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]