lilypond-user
[Top][All Lists]
Advanced

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

Re: Bar lines


From: David Kastrup
Subject: Re: Bar lines
Date: Thu, 07 Mar 2013 10:06:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Marc Hohl <address@hidden> writes:

> Am 06.03.2013 21:24, schrieb David Kastrup:
>> Marc Hohl <address@hidden> writes:
>>
>>> I am a bit disappointed that the discussion about \bar ":|."
>>> rises half a year after the patch went through the revision
>>> process.
>> If you think this is the first time, you have missed a few times.  The
>> revision process does not incorporate user feedback that we have seen in
>> between, and it is usually rather sloppy.  If I would complain every
>> time a feature of mine did not get any review at all during the regular
>> review phase, people would be even more annoyed at me than they already
>> are.
> Yeah, ok. Perhaps I was in some bad temper when I wrote that.
>
> In my opinion, the bar line stuff was not logically structured before.
> As Harm pointed out, it was a mixture of shorthands, WYSIWYG and
> whatnot.

Sure.  It was sort-of-WYSIWYGgish.  It was not a comprehensive set, and
it was a closed set.

The new barline syntax does not really offer WYSIWYG.  What it does
offer, is a nice and coherent interface to specify barline _recipes_.

Now if \bar ".||:||." or similar would function without further ado,
this would provide independent value.

But it doesn't, since we need \defineBarType to get the specification
for pre-break, post-break, spanbar look.  If we need \defineBarType
anyway, there is no need to force the non-break recipe to be identical
to the bar type.

Personally, I'd only define shorthands for the most commonly used bar
types, and make these shorthands as short and mnemonic as possible to
make them separate from one another.  If that corresponds with the
non-break recipe, fine.  If it doesn't, also fine.

Fitting more bar types in becomes the problem of the user.

> The new interface is a 1:1 representation of the output in terms of
> glyphs. Period. I think this is an improvement.

Sure.  But we are talking about the representation of the input right
now.

> Another example: assume I want a certain part being ended with "||".
> The next part is a repeat, so I have to use ".|:-||" for this. *Very*
> counterintuitive and annoying.

Even as a recipe, I find it somewhat aggravating.  If we relax the
connection between input and recipe, we might allow some forms of recipe
that are _not_ represented by just a single string.

> But here you come to the point of engraving music vs. writing music.
> The engraving process as such means nothing else than "stencil two
> dots in the plate, scratch a thin line and a thick line at the end of
> the next bar" – so writing \bar ":|." (apart from the dot being a poor
> interpretation of a thick bar line, _not_ for the end of a phrase, at
> least for me) is /engraving/.
>
> When I compose a piece of music, I don't think in terms of engraving,
> but in structures.

Structures are made of components, but components are not glyphs but
merely _represented_ by glyphs.

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.  I can also imagine recipes/definitions like

(define-bar-type "|:"
  ".|:" :prebreak "|" :postbreak ".|:" :spanbar ("xxx" "yyy"))

-- 
David Kastrup




reply via email to

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