(sorry, Keith, forgot to cc the list)
On Wed, Sep 5, 2012 at 10:59 AM, Keith OHara <k-ohara5...@oco.net> wrote:
> The broad question is: Require delimiters to clarify context (for users,
> LilyPond, and software importing LilyPond) -- more or less?
On Wed, Sep 5, 2012 at 11:54 AM, Trevor Daniels <t.dani...@treda.co.uk> wrote:
> There are many places in LilyPond now where delimiters are necessary
> to resolve certain situations but are not generally mandatory. Perhaps
> this approach could be extended.
+1
(On Wed, Sep 5, 2012 at 10:59 AM, Keith OHara <k-ohara5...@oco.net> wrote:)
> The broad question for these three is: Syntax that changes depending on the
> definitions of the functions in the input -- good or bad?
looks bad for me (but i'm no expert).
On Wed, Sep 5, 2012 at 11:47 AM, Keith OHara <k-ohara5...@oco.net> wrote:
> Janek Warchoł <janek.lilypond <at> gmail.com> writes:
>
>> I think that for the next several weeks we should focus on gathering
>> information about the /problems/ people have. Not the ideas for
>> solutions. Problems.
>>
>> For example,
>> "in { a \parenthesize b \mf c d } it's confusing what gets
>> parenthesized and what gets mezzoforte"
>> is a description of a problem, while [...]
>> is a solution. Lets talk about problems first, then solutions.
>
> I think I have that problem, but maybe not exactly what you mean.
>
> Does the confusion you refer to happen more in reading (other people's)
> Lilypond input, or in writing your own Lilypond input?
When i'm writing Lily code. And when i'm teaching Lily to other people.
On Wed, Sep 5, 2012 at 12:37 PM, David Kastrup <d...@gnu.org> wrote:
>
>> Keith OHara wrote:
>> I've seen complaints in non-Lilypond forums that LilyPond pitch entry is not
>> relative to key signature. We could accommodate this by re-defining pitch
>> names upon seeing
>> { \keyAffectingEntry \d\major ... }
>> so that f means F-sharp and we have to type fn for F. (This requires
>> pushing a
>> pitchname-table on a stack for every nested level of {} or <<>>)
>
> My personal take on this is "no". Reason 1 is that then the actual
> pitch will depend on _input_ accidental rules. That will make MIDI and
> MusicXML output less predictable. Reason 2 is that a human-oriented
> linear non-graphic representation of what is usually seen graphically
> should resemble the manner in which humans would talk on the phone, a
> similarly linear medium. I don't know other note language conventions,
> but here in Germany you would _never_ call a fis an f just because its
> accidental is contained in the key signature. Totally unthinkable even
> among amateurs. You'd immediately get "Oh, this is supposed to be an f?
> How do you tell?". Not because of nitpicking, but because nobody would
> guess that f would be used to describe a fis.
I'd say we could have a movable do for this purpose:
\movableDo { \key d \major do re mi fa sol la si do } == \key d
\major d e fis g a b cis d
Janek
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
