lilypond-user
[Top][All Lists]
Advanced

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

Re: sharping naturals


From: David Kastrup
Subject: Re: sharping naturals
Date: Mon, 10 Aug 2015 13:47:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> If I understand correctly your proposal is that
>
> \language "english"
>
> m = { ff' f' fs' }
>
> \m
> \follow fs \m
> \follow ff \m
>
> will be printed different.

Well, it would be more likely

\follow <fs> \m
\follow <ff> \m

here.  That would be _one_ basic idea of implementation.  This one would
mark non-explicit pitches c d e f g a b specially so that \follow can
distinguish them from cn dn en fn gn an bn.  The "unspecificness" would
be kept in the music.  How and when should it get resolved when there is
no \follow involved at all?  What happens if we \transpose music
containing unspecific pitches?

Another implementation would be to keep the music expressions
unambiguous and instead use a different notename language variant,
perhaps invoking it like

\language \key a \major "english"

which will redefine all "unspecific" note names in correspondence with
the key.  Or maybe just

    \languagekey a \major

That will basically make the typical document be written in a large
variety of notename languages which makes for a lot of fun when editing
and/or copy/pasting motives around.  In particular, editing
functionality like that of Frescobaldi (which may be asked to transpose
passages for the user) will become unreliable, and the inability of an
external tool to figure out the right pitches without context of course
is matched by a similar potential for confusing users.

> In my thinking that's absolute crude.
> Though, obviously there are other opinions about that.
>
> Patches are always welcome.

But one needs to be warned that they may meet resistance to acceptance,
so there is some sense in figuring out the other developers' opinions
before investing a lot of work, at least if one's ultimate goal is the
inclusion as an integral part of the standard LilyPond distribution.

A somewhat smaller but comparable can of worms is \relative mode.
A frequent topic on the mailing list is "how do I make my music
functions work in \relative mode?" and often answers are not
straightforward.  Many LSR snippets work only either in absolute mode or
in relative mode, and not necessarily reliably so.

So it is pretty much established that the music-based approach comes
with a healthy load of problems, and the input language based approach,
while condensing most of the problems in one place, makes source code
management a headache because each source code passage comes with its
own associated input language.

-- 
David Kastrup



reply via email to

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