Re: Bar lines

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2013/3/6 David Kastrup <address@hidden>:
>
>> It is orthogonal to us making \bar "|:" and \bar ":|" well-defined by
>> letting : automatically imply a thick bar since nothing else makes
>> sense.
>>
>> We don't want to point users having a simple understandable problem
>> to an explanation for a large problem complex, no matter how good
>> that explanation is.
>>
>> We are using things like "|:" and ":|" because they are semi-WYSIWYG
>> and thus intuitive.  If people write repeats in non-formal ASCII
>> lyrics, like "we'll see this problem, |: time and again :|", they
>> will not write .|: or :|. since only typesetters realize that repeat
>> signs at the end of a piece are indistinguishable from normal repeat
>> signs.
>
> You mentioned your concerns before (can't find it right now), though,
> personally I see no _coding-problem_.

Good.

> Well, I might be biased, because, although Marc did the major work, I
> spent a lot of time and work on the new barline-interface, too.
>
> But ofcourse you're right here:
> a)
> In a text I'd write
> p.e
>   "
>    This is the "Barform":
>    |: Stollen :|
>      Abgesang
>   "
> b) The present barline-interface is "pure" WYSIWYG

And one of the points of LilyPond is that it does the right things
visually without requiring the user for everything.

> c)
> The first for any user noticable novelty is the change from \bar ":|"
> to \bar ":|."
> dito for other repeat-signs.
> This is covered by a convert-rule.

Sure.  The question is not how to avoid users having to change habits.
The question is what the best user interface would be for someone not
having previous exposure to LilyPond.

> Ok, you'd prefer processing ":|" as colon-thin-thick-barline with no
> need for a converting-rule.
> Well, here I think different: I do like the "pure" WYSIWYG-approach
> and I'm not convinced that a semi-WYSIWYG-approach would really be
> more intuitive.

You are assuming that the average user is aware of the visual
composition of repeat signs.  But that's LilyPond's responsibility.

We use "|." for the end bar not because of its _visual_ properties, but
because of a _logical_ property, ending a piece.  WYSIWYG would be "I"
or "|I" or "|]" instead (again, it is not really the job of the user to
remember that a thick bar line is always accompanied by a thin one, so
he writes something akin to "give me a bar line fit for ending a
piece").

"." is in no way a thicker bar line than "|" is.  So the whole "WYSIWYG"
analogy/principle is a rather strained one, and that means that nobody
will understand it without getting a thorough explanation.

> What do other users/developers think?

My guess would be that they trust the programmers to have good reasons
for doing things like they do.

I am also pretty sure that in a "frequently asked questions" list for
LilyPond, this one will end up occupying a rather high place.  And I
don't think that is warranted.

> Can we reach a consensus?

Well, I am a doomsayer faced with optimists.  The easiest way to reach
consensus is to just wait.  I just doubt that we are doing our users a
favor with that...

>> Do we really need to give _every_ _single_ person on the user list
>> the same advice, again and again?
>
> My first thought would be: Let us improve the documentation.

Eure Rede sei "Ja, Ja, Nein, Nein".  Alles, was darüber hinaus ist, ist
von Übel.

The difference between a bad music instrument and a good music
instrument is not that a good musician can only make good music on a
good instrument.  The difference is that a good instrument lets him
focus on the music rather than on the instrument, and thus enables him
to become a good musician in the first place.

I have enjoyed working on the Bach solo partitas and sonatas.  They are
really tough (containing four part fugues for the violin, not an
instrument typical for chord play), but the toughness is not
self-serving but serves a musical purpose.  You can play the Urtext
easily since there never is a serious question about fingering.  For
much of the material, there is a single fingering making much more sense
(or even being possible) than any other fingering.  You don't need
documentation to figure out how Bach wants you to work with your violin.

Working with LilyPond is inherently complex, so people have to learn
dealing with complexity.  But I want them to get a reasonable payback
for that and not get them exhausted on things that don't help them get
better into LilyPond.

When people consult the documentation, I want them to primarily learn
something about LilyPond rather than about its developers.

>> While it is quite more efficient to condense it in the manual and
>> point to that, pointing every single user to this manual section is
>> going to get old as well.
>
> Well, yes, though, every new code which is expected to be used by
> every LilyPond-user will need some time before it is fully understood
> and excepted. It was (and sometimes is) the same with the
> beaming-rules and spacing-procedures introduced with 2.14.

I am not sure our spacing procedures have been accepted.  From a user
interface design point of view, they are O(n^2) which scales rather
badly.

I think we'd fare better with a user interface specifying before/after
space of any construct, with LilyPond constructing

x-y-spacing = max (after-x-spacing, before-y-spacing)

by itself.  That's a much more natural view.  It offers fewer
possibilities, but most of the additional possibilities don't even make
sense, so having more possibilities does not correspond with having more
power to do useful things.

>> After telling enough people "the problem is actually simple, it is
>> just you who are incompetent", maybe we should think twice about what
>> we have to gain by making LilyPond users feel incompetent.
>
> I never wrote or intended that!!
> If any user feels offended by the style/manner of my explanation I
> very much apologize.

Misunderstanding here: I was not complaining about your explanation, but
rather about it being needed in the first place.  Yes, there will be a
point where one needs documentation, and there will be a point where one
needs to thoroughly think about things.  But the longer we can postpone
these points, the more empowered and competent our users will feel.

Because we are giving them an instrument making it easier for them to
achieve their goals, letting them focus on their goals rather than on
fighting LilyPond.

That's a lot of verbiage for a small issue.  It will be easier to
convince you once you have answered the respective user mails for a year
or so.

And I am pretty sure that they'll continue to arrive.

-- 
David Kastrup