> > __________________________
> > |1.-3. | Fine | 4.
> > ....... :| ........ || ............ |
> > Da Capo
>
> if the need arises, we should be able to devise something for say
>
> ____________________________
> |1. | 2.-4. | 5.
> ...... :| ........ | ........ |
>
> (suggestions and patches appreciated :-)
>
> we thought about about all kinds of "jumping" (Da Capo, Coda, al Signe,
> menuetto stuff, etc.) and decided not add logical language support for
> that. It's hairy, there are too many different combinations, it's
> possibly ambiguous, and there seems very little need to do so from a
> typesetting point of view.
I agree completely. The only thing I missed was the ability to
set the text for each alternative freely.
> > Do we really need the \repeat at all. Why not typeset the repeat signs
> > manually with \bar as before? The semantics is still clear from the input
> ...
> > if we want to generate midi files with "unfolded" repeats.
>
> Well, we'd need to add something for the volta's then...
Yes, that was my idea, to keep something like \alternative without
the \repeat, but reading ...
>
> \notes {
> \repeat 65 { { a b c } }
> }
>
> means, repeat this 65 times (no alternatives here).
> We'll need to know the 65 for barnumbering and unfolding.
... I realize why you choose the currect construct. Looking at parser.y
I didn't notice that the Alternative_music could be empty. My fault.
> > Finally it must be possible to get rid of some of the curly braces,
> > it starts to look like LISP.
>
...
>
> For the \repeat they're just a hack...
> Suggestions?
I haven't really thought about it, but what about
- Repeated_music: REPEAT unsigned '{' Music '}' Alternative_music {
+ Repeated_music: REPEAT unsigned Music Alternative_music {
would it break the whole syntax? You already have shift-reduce conflicts.
/Mats
