Marc Hohl <m...@hohlart.de> writes:
> David Kastrup schrieb:
>
>> But the point is that "repeat volta" and "coda" and whatever else in
>> the music list should be just interesting for the grob engraver, and
>> performer and repeat unfolder and cautionaries and stuff get their
>> info from a lower-level primitive data structure.
>>
> I agree. So We need both a data structure flexible enough to cover
> all possible cases, and an input mechanism which is consistent and
> yet not overwhelmingly complicated from the user's view.
>> Like a compiler compiling conditionals to jnz, the high level language
>> with which we specify the structures should be powerful enough to avoid
>> the explicit use of "goto" whenever possible.
>>
>> But there might be some user-level description of the logical structure
>> that can get by without use of "goto" at the input level, even though it
>> may get compiled to such.
>>
> In principle, I second this. A perfect implementation should (at least
> in my opinion)
> make the input source nearly as readable and understandable as the
> musical output,
> so perhaps structuring the input file with
>
> \coda {
> ...
> }
>
> \trio {
> ...
> }
>
> and some \toCoda/\toTrio commands might be necessary, though.
Yes, some possibilities for standard situations like that would be
really fine: in general, the user should be able to express the logical
structure of his input, rather than having to mess with placing repeat
sign markups (necessary now) and declaring performance order (not
possible now).
For non-standard notation, being able to do manual markup without losing
the possibility to unfold and/or perform unless you are a magician will
still come in handy.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
