lilypond-user
[Top][All Lists]
Advanced

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

Re: Bar lines


From: Janek Warchoł
Subject: Re: Bar lines
Date: Thu, 7 Mar 2013 12:01:34 +0100

Hi all,

On Wed, Mar 6, 2013 at 10:18 PM, Noeck <address@hidden> wrote:
> Before trying it out and writing my first mail, thought I could use
> custom barlines now out of the box. Would it make sense to have that?
> I will explain what I mean:
>   \bar "|!."
> would print a bar equivalent to a definition:
>   \defineBarLine "|!." #'("|!." "" "|!.")
> If you want a different definition you would have to write it, of course.

sounds interesting.  I think David suggests something similar.


On Thu, Mar 7, 2013 at 9:28 AM, Marc Hohl <address@hidden> wrote:
> Am 07.03.2013 00:13, schrieb Janek Warchoł:
>> ok, good point; replace that with:
>> if the music is more than 3 bars long, use a final barline; if it's 3
>> or less use a regular barline.  That's 100% predictable, i think.
>
> Hmmm – I think this is a rule that I cannot memorize for sure;
> I'll have to check by trial-and-error whether lilypond does what I want or
> not.
>
> As mentioned in another mail, I'd go for something like
> \set Score.finalBar = "|."
> within ly/engraver-init.ly

yes, this was the first part of my suggestion.
I proposed this "decide-based-on-bar-count" idea to make writing
snippets and music exaples (that shouldn't end with final barline)
easier.


On Thu, Mar 7, 2013 at 10:06 AM, David Kastrup <address@hidden> wrote:
> [snip snip]
> Ok, here is the deal: I promise to give real thought about a way to
> _define_ repeat structures in such a straightforward manner that a user
> would understand how to create repeat structures of his own including
> working Midi and \expandRepeats as long as he can hack together the
> glyphs for the _looks_.
>
> And you promise think about how the barline definition interface might
> be made more friendly when in-line recipe and call string are not forced
> to be the same, and how more complex recipes might benefit from not
> being string-only.

Sounds like a good candidate for consensus.  I like this direction,
and i'll gladly help with reviewing specific user interfaces.

best,
Janke



reply via email to

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