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: Janek Warchoł
Subject: Re: bar line interface / repat structure considerations
Date: Wed, 13 Mar 2013 17:05:08 +0100

Hi Marc&all,

On Wed, Mar 13, 2013 at 10:09 AM, Marc Hohl <address@hidden> wrote:
> make
> sure you sit comfortable and have a nice cup of coffee, tea or whatever
> around...

these words actually reminded me that i had a tea waiting, and thanks
to you it didn't get totally cold before i drank it :)

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

I like this, except that i'm not sure whether the keywords :prebreak
:postbreak etc don't clutter the view too much.

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

I like this. I saw that David has some objections, so i don't insist,
but i'm pretty sure that beginners would appreciate this a lot.

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

I agree that the guessing shouldn't get overly complicated.

thanks,
Janek



reply via email to

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