Re: bar line interface / repat structure considerations

[Marc Hohl]

Am 13.03.2013 10:27, schrieb David Kastrup:
> Marc Hohl <address@hidden> writes:
>
> > Hello list,
> >
> > after some discussions on -user (partly emotional - sorry for that!)
> > I promised to think about improving the bar line interface. Well,
> > hereare some preliminary results. The mail got a bit long, so make
> > sure you sit comfortable and have a nice cup of coffee, tea or whatever
> > around...
> >
> > 1) It seems to be a problem that users cannot usethe shortcuts "|:"
> > ":|" for repeats any more – using ".|:" ":|." is the 1:1
> > string-to-glyph representation, but conterintuitive.  This could be
> > circumvented to a certain amount by replacing the dot '.'  by a
> > character that looks more like a thick bar line. We had discussions on
> > that topic, but no results, so I think this will not solve the problem
> > completely.
> We have some "annotation" syntax for implying different linebreak
> behavior, and that's really where the current approach is starting to
> become very strained.
Yes. When I was writing the bar line interface, I thought that
this was a good idea, but well ...
> > 2) IMHO, LilyPond should provide more tools for structuring the music.
> > The \repeat mechanism is not suitable for da capo, dal segno, or even repeat
> > alternatives like
> >
> > ______________ _____________ ____________
> > | 1.2. :|| 3. :|| 4.
> >
> > without scheme-ish constructsand a certain amount of trial-and-error.
> > This would probably solve most of the problems with manual bar line
> > commands.
> Most?  I don't think so.  For one thing, we'll still need a way to
> define/configure the bar line types to employ to cater for different
> styles of typesetting.
I think most of this can be done with properties similar to those that 
already
exist:

defaultBarType = #"|"
doubleRepeatType = #":..:"
startRepeatType = #".|:"
endRepeatType = #":|."

why not add

endPartType = #"||"

and the likes? IMHO an ideal way of handling bar lines would be
not being forced to use \bar command at all for most of the common
notation tasks.



> > What about someting like
> >
> > \repeat volta 4 { ... }
> > \alternative {
> >    "1. 2." { ... }
> >    "3. " { ... }
> >    "4. " { ... }
> > }
> >
> > and, in addition
> >
> > \repeat dacapo { ... \toCoda ... }
> > \alternative {
> >    "Coda" { ... }
> > }
> >
> > \repeat dacapo { ... \Fine ... }
> >
> > \repeat segno { ... \Segno ... \toCoda ... }
> > \alternative {
> > "Coda" { ... }
> > }
> That's an input syntax.
Well, the bar line interface discussion is about input syntax.
>    I prefer tackling the basic
> definition/representation/unfold mechanisms first and then seeing what
> user interface to tie them with.
Ok.
>    One reason I am skeptical about this
> particular suggestion is that more often than not (like the typical
> multi-stanza pop song with a separate ending), D.S.a.C is _intertwined_
> with a repeat volta.
LilyPond already allows for nested repeats, but one has to
take case for ambiguities, that's right.
> > b) if the user writes \bar "S.S" without defining it before,
> > LilyPond does (define-bar-line "S.S")herself, therefore
> > allowing the user to write bar lines "on-the-fly".
> Sounds tricky.  I am also not sure that it is a good idea to hide that a
> particular bar type just has "best guess" support.
Oh, sorry, I meant

\bar "S.S"

leads to

(define-bar-type "S.S" "S.S")

A warning that one uses a bar line not properly defined
can be raised, of course.
> Even if the user only acknowledges this by writing
> #(define-bar-type "S.S")
> and thus signifying "I am ok with all the default choices".
What would you propose instead?
> Also, the guesswork should be straightforward, and obviously
> overridable.
If we allow for guesswork at all.

The current interface ignores unknown bar lines (that's not
ideal) but forces the user to define bar lines before using it.
We can stick to that behavior and raise warnings like

(define-bar-line "myBar" "S.S")

"warning: you define a bar line without line breaking decisions and span 
bars.
LilyPond uses "S.S" at the end of line and as span bar, too."

But that makes LilyPonds output rather wordy IMHO.