lilypond-devel
[Top][All Lists]
Advanced

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

Re: [frogs] Da Capos, Codas and Segnos


From: David Kastrup
Subject: Re: [frogs] Da Capos, Codas and Segnos
Date: Tue, 16 Feb 2010 22:55:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (gnu/linux)

Marc Hohl <address@hidden> writes:

> After reading through the other posts, I think that overloading
> \repeat would not cover *all* possible
> cases. On the other hand, there should be *one* consistent way of
> doing any kind of repeats.
>
> David's comparison with goto-like structures seems to be the right
> approach, so I revert my
> proposal about enhancing \repeat for a more universal structure.

Oh I think we are not communicating.  I liked your proposal quite well,
even though it did not cover "everything conceivable".

What I was talking about that in order not to have a proliferation of
things that work/expand with only a subset of the supported repeats,
that the internal music data structures gain a few "linkages" or
whatever you want to call it that cover the possible sequencing.

For example, one could have an element "multibranch" that contains a
sequence of music list tails (or #t to continue on the printed score).
When this element is passed/played the first time, it takes the first
branch, then the next...  It should be reasonably easy to perform this
with this info, and reasonably easy to produce the right amount of
preannounce material.  Doing cautionary accidentals correctly needs the
reverse information, namely instead of "where can I be going to from
here" the info "where can I be coming from here".

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.

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.

-- 
David Kastrup





reply via email to

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