lilypond-devel
[Top][All Lists]
Advanced

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

bar line interface / repat structure considerations


From: Marc Hohl
Subject: bar line interface / repat structure considerations
Date: Wed, 13 Mar 2013 10:09:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3

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.

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.

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" { ... }
}

3) Even with the current repeat mechanism, the user has to fiddle with
bar lines manually:

c1 \bar "||" \break
\repeat volta 2 { d1 | e1 }

makes the "||" disappear at the end of the line; one has to use \bar ".|:-||"
for this purpose.
Something like \endPart which draws a endPartType barline (predefined as "||")
and cares for following repeat signs automatically would be grat IMHO.

4) Ok, now the bar line interface stuff. There were complaints that the
current mechanism has three flaws: first, the input string resembles the output
glyphs 1:1which makes the input complicated (see (1)) - separating input and
outputwould allow for easier bar line handling.

Second, the span bars should be defined for the line breaking situations as well.
Currently, we have for example

(define-bar-line ".." "." "|" "..")

and have to define the span bars for "." and "|" in separate commands.
That's far from optimal and is addressed in issue 2918 <http://code.google.com/p/lilypond/issues/detail?id=2918> already.

Third, the user has to define a bar line before using it, with all the span bar
and probably additional stuff that may be unnecessary, because he knows that
his bar line appears in single staves only or in the middle of a line only.

The predefined bar lines look like this:

bar line prebreak postbreak spanbar

"" "" ""        #f
"-" #f #f        #f
"|" "|" #f        "|"
"|-s" #f "|"       "|"
"." "." #f        "."
".|" "|" ".|"      ".|"
"|." "|." #f        "|."
"||" "||" #f        "||"
".." ".." #f        ".."
"|.|" "|.|" #f "|.|"
"!" "!" #f        "!"
";" ";" #f        ";"
"'" "'" #f        #f
"k" "k" #f        #f

":|.:" ":|." ".|:"     " |."
":..:" ":|." ".|:"     " .."
":|.|:" ":|." ".|:"     " |.|"
":.|.:" ":|." ".|:"     " .|."
":|." ":|." #f        " |."
".|:" "|" ".|:"     ".|"
"[|:" "|" "[|:"     " |"
":|]" ":|]" #f        " |"
":|][|:" ":|]" "[|:"     " | |"
".|:-||" "||" ".|:"     ".|"

"S" "||" "S"       "="
"S-|" "|" "S"       "="
"S-S" "S" #f        "="
":|.S" ":|." "S"       " |."
":|.S-S" ":|.S" ""        " |."
"S.|:" "|" "S.|:"    " .|"
"S.|:-S" "S" ".|:"     " .|"
":|.S.|:" ":|." "S.|:"    " |. .|"
":|.S.|:-S" ":|.S" ".|:"     " |. .|"

For single bar lines(the first couple of lines), we have
often span bar and prebreak equal to the normal bar line,
so we might use the following rules:

a) replace the current mechanism by a command
(define-bar-line <shortcut>
(<bar-glyph> :prebreak <prebreak-glyph>
:postbreak <postbreak-glyph>
:span-bar <span-glyph>
:prebreak-span <pre-span>
:postbreak-span <post-span>))

where :prebreak, :postbreak, :spanbar, :prebreak-span and :postbreak-span
arguments are optional,and we define (in quasi-Lua syntax :-)

<prebreak-glyph> = <prebreak-glyph> or <bar-glyph>
<postbreak-glyph> = <postbreak-glyph> or #f

<span-glyph> = <span-glyph> or <bar-glyph>
<pre-span> = <pre-span> or <prebreak-glyph>
<post-span> = <post-span> or <postbreak-glyph>:postbreak-:post::postbreak-span postbreak-span break-span span

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".

During the development of the current interface, Harm proposed some
very tricky mechanisms where LilyPond kind of guesses what the user
wants to achieve, so repeat signs were handled quite properly out of
the box (including their span bar apperance), but IMHOweshould not try
to make the bar line interface too clever.If a user wants a more
sophisticated bar line, he/she probably knows how the span bars and
line breaking decisions should look like without the needd to fight against
some automatic trickery.

That's all, thanks for reading ;-)

What do you think?

Marc








reply via email to

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