Keith OHara <k-ohara5...@oco.net> writes: > 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.
I proposed already at one point of time to require writing 4.0 rather than 4. for the floating point number. This will not cure a lot of use cases, and we still have the ambiguity between 4 the duration and 4 the integer, and -4 the fingering and -4 the integer. Some of those can be resolved in context, but this does not help for conversions, and we also have largely context-free situations, like in #{ ... #} or on the right side of assignments. At the current point of time, I can't write things like #{ 4.0\cm #} in appropriate contexts because 4.0 is not recognized in notemode as a real number. Writing #{ $4.0 \cm #} would work but it does not exactly win a price for beauty. > One situation where LilyPond /does/ require delimiters is > \chordmode { c4:8 } That's because it changes the lexer modes. Switching back reliably is only possible when you have a closing delimiter that can still be scanned in the inner lexer mode, so that you are in outer lexer mode again before even having to start looking at the next token. > The broad question is: Require delimiters to clarify context (for > users, LilyPond, and software importing LilyPond) -- more or less? Where necessary. > 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. So this is at least for me a very definite "this is not even open to consideration" area. Of course, people deserve to be told just _why_ it is such a bad idea. > 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. Just because some part of LilyPond syntax is defined as music functions, that does not mean that one can't describe it formally. The poor guy writing the .ly in Musescore at least has a chance of designing a single mechanism able to recognize _all_ variants of music functions that we permit. That makes it easier for him to _systematize_ his work. > The broad question for these three is: Syntax that changes depending > on the definitions of the functions in the input -- good or bad? Essential to LilyPond's design and expressivity. That does not mean that we should not try maximizing the good aspects and minimizing the bad aspects. > 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, A LilyPond-to-LilyPond conversion would at least rip out user-defined functions and render the predefined ones, where necessary to represent music expressions, in a predictable manner. > .. and that LilyPond will keep its freedom from delimiters, with David > pulling LilyPond further toward scanning the input independent of > context. Again, this is not achievable in the absolute. But there is still leeway to do better than we have. And being able to get along with fewer modes also means that one does not need to choose between the respective benefits of several modes, but can profit from the combination. > 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. Ugh. Do we really have both? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel