[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bar line interface / repat structure considerations
From: |
David Kastrup |
Subject: |
Re: bar line interface / repat structure considerations |
Date: |
Wed, 13 Mar 2013 10:27:22 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
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.
> 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.
> 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. I prefer tackling the basic
definition/representation/unfold mechanisms first and then seeing what
user interface to tie them with. 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.
> 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.
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".
Also, the guesswork should be straightforward, and obviously
overridable.
--
David Kastrup
Re: bar line interface / repat structure considerations, Janek Warchoł, 2013/03/13