lilypond-devel
[Top][All Lists]
Advanced

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

Re: how to make decisions?


From: Keith OHara
Subject: Re: how to make decisions?
Date: Wed, 5 Sep 2012 08:59:26 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Trevor Daniels <t.daniels <at> treda.co.uk> writes:

> So what problems do the users have, exactly?  We should address this 
> question first.  Janek apparently has his list, which would be a good start.
> But we should not invent problems where they don't exist.  I've probably 
> read every email on the user list for the last 4 years, and inconsistent 
> parser rules have not figured prominently.  

I generally agree.  But I also have sympathy for the desire to first clarify 
some broader questions  -- such as, in which /direction/ to straighten out the 
parser when user problems require changes to the parser.

I understand that past catering to concrete user needs has gradually resulted 
in a messy syntax, very difficult to import into other systems (musescore 
tried), which also makes it harder to cater to some current user desires.

The readable  \tempo "Adagio" 4. = 30~40   lacks the delimiters that most 
computer-entry formats require, which made it unusable in a \midi block for 
many years -- because LilyPond accepts decimal-point numbers in the midi block, 
for probably another good reason.  Without requiring delimiters it is hard to 
specify exactly when LilyPond should read 4. as a duration, and when as 4.000.

One situation where LilyPond /does/ require delimiters is \chordmode { c4:8 }

The broad question is: Require delimiters to clarify context (for users, 
LilyPond, and software importing LilyPond) -- more or less?


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

Digits-in-identifiers is an often-requested feature that seems it should be 
easy (if we are willing to require a space in \skip 4 and \tuplet 2/3).  The 
trouble is that I cannot use vn1 = {..} without either telling the lexer that 
"vn" will never by a note-name in any language, or requiring some structure to 
specify when music functions are done:  \afterGrace ces2 des8 vn1 = c2.

I used to use \cueWhile, but then switched to your \cueDuring with the extra 
parameter, and had a few mysterious errors when I forgot which one had the 
extra parameter.  David of course suggested I make a \cueDuring with an 
optional parameter.  Either way, the poor guy writing the .ly importer in 
Musescore has no hope to keep up.

The broad question for these three is: Syntax that changes depending on the 
definitions of the functions in the input -- good or bad?


My prediction is that LilyPond will keep its syntax that requires knowledge of 
the definition of functions to be parsed correctly, thus un-importable by other 
software,

.. and that LilyPond will keep its freedom from delimiters, with David pulling 
LilyPond further toward scanning the input independent of context.

Others certainly frame the broad questions differently, and probably see 
additional broad questions. I think we need to allow some time for compromise 
on these balances between philosophy and practicality.

Many of the specific items on the GLISS list concern names of things, which I 
think is independent of the broad questions, but will solve some real 
problems.  I was quite puzzled by a question on -user yesterday, until I 
realized he had confused the purposes of Staff.keySignature versus 
Staff.KeySignature.




reply via email to

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