lilypond-user
[Top][All Lists]
Advanced

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

Re: Changing voice order...


From: David Kastrup
Subject: Re: Changing voice order...
Date: Tue, 01 Nov 2016 15:42:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> Simon Albrecht wrote Tuesday, November 01, 2016 10:42 AM
>
>>On 27.10.2016 13:40, David Kastrup wrote:
>>> This concerns << ... \\ ... \\ ... ... >>
>>>
>>> If we have more than one voice, voices are assigned in order:
>>>
>>> 1/2, 1/2/3, 1/2/3/4, 1/2/3/4/5, 1/2/3/4/5/6 ...
>>>
>>> while the documentation is quite explicit that, ordered from top to
>>> bottom, assignments should be more like
>>>
>>> 1/2, 3/1/2, 3/1/2/4, 5/3/1/2/4, 5/3/1/2/4/6 ...
>>
>> That should rather be
>>
>> 1/2, 1/3/2, 1/3/4/2, 1/3/5/4/2, 1/3/5/6/4/2.

See?  Even I get confused by what we have currently.

>> The current mechanism at least provides consistency between the 
>> \voiceOne, \voiceTwo… command names and the order in << \\ \\ >>. And I 
>> don’t see how strict top-down numbering would be less confusing in 
>> general. Indeed, I think that the current rules make a lot of sense, 
>> once one has gotten the idea.
>
> I agree with Simon.  I don't agree the proposed change would be
> clearer.

There are by now two components to my proposal: fading out \voiceOne
... \voiceFour since they _never_ correspond to voices 1/2/3/4 in a
four-voiced context but to voices 1/4/2/3.  And changing the meaning of
<< \\ \\ \\ >>.

> Definitely not worth the hassle.  Far better would be to concentrate
> on improving the documentation, if it is thought that is not clear
> enough.

I think that most work should be accomplished without having to consult
the documentation: vaguely remembering << \\ \\ \\ >> should be enough
to use it again since for a lot of non-trivial tasks there is already
enough documentation that you'll need to consult.  The more stuff works
just like you seem to remember it, the better.  The documentation is no
excuse for a confusing interface.  I'm going to do a LilyPond talk this
weekend: stuff like that is really embarrassing to show and explain.  It
turns people off and establishes the impression that LilyPond is obscure
software for specialists.  I want people to have a great return of value
from reading the documentation: learn about something, and be able to
use it with confidence.

How about we check out Mutopia?  It is my guess that a considerable
number of the uses of << \\ \\ \\ >> construct with three or more voices
are wrong.  Simply because I have a hard time getting it right myself.

We want our users to be successful musicians, not successful manual
students.  Of course they are related and that relation is a justified
cause of pride to the people maintaining the manuals, but we still
should take care that when in doubt we are putting the horse before the
cart.

-- 
David Kastrup



reply via email to

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