Re: Changing voice order...

[David Kastrup]

"Br. Samuel Springuel" <address@hidden> writes:

> I'm not a heavy user, so take my thoughts with whatever grain of salt
> you want, but this is how I would naively expect these constructs to
> work:
>
> << \\ \\ \\ >>
> The voices would be entered in order from top to bottom.  In this way
> the physical structure of the code would resemble the structure of the
> music I'm entering (thanks to line breaks in the code between the
> voices).
>
> \voiceOne \voiceTwo \voiceThree \voiceFour
> The numbers here are confusing.  They could be a top-down enumeration
> of the voices or a more musical outside to inside pattern.  Further,
> the fact that they don't match up with the 1/2/3/4 numbers of the
> implicit code above is even more confusing.  If we stick with numbers,
> then numbers should match.  However it would probably better if we got
> away from numbers altogether here.  Kieren's suggestion of \voiceUp.1
> and \voiceDown.1 seems somewhat more natural, but the numbers still
> have the potential for confusion.  I do not know how to solve this (if
> it's solvable).

That's why I wanted to use something more akin to directions.

> Finally, as a coder I always favor a phased process for changes to the
> user interface so that people have time to adapt to the change.  A
> flag which can flip between the new and old behavior is definitely in
> order until 3.0.0 comes out.

Yes, something like this will be provided for << \\ \\ \\ >> but there
is nothing that can help with \voiceOne/\voiceTwo/\voiceThree/\voiceFour
since those work without context.  So I'd rather phase out those name
choices for something nicer.

> I'd default the flag to the old behavior while the new one is being
> worked on and then default it to the new behavior once a stable state
> has been reached.

I don't see that "the new one" will be worked on for any significant
amount of time.  The change is not involved.  Its implications aren't.
Without a rather good track record of convert-ly on LilyPond's code
base, this change is not going to go through.  Most convert-ly rules are
"robust" in that you can run them multiple times and only the first
application will cause a change.  Also the syntax without convert-ly run
tends to be bad, causing errors.

Neither will be the case here, so that is going to end up a bit of a
support headache for a while.  On the plus side, \\ is rarely used for
more than two voices, or if it is, the voice settings tend to get
overridden manually.  In which case a conversion does not need to do
much.  I think that a convert-ly rule should likely not change the order
of entered voices but should just add a command for "flipping the flag"
instead if more than two \\-separated voices are detected without
explicit voice setting commands.

-- 
David Kastrup