lilypond-devel
[Top][All Lists]
Advanced

[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




reply via email to

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