Alexander Kobel <a-ko...@a-kobel.de> writes:
> What about \voiceUp<Digit> and \voiceDown<Digit>? Where the former are
> counted from top to bottom, and the latter from bottom to top?
I prefer it if a LilyPond source is readable without explanations. That
makes it much easier to learn by example and feel confident about it.
It also makes stuff like Frescobaldi document templates work better. If
the template appears to make sense, people are more comfortable using it
(and remembering and reproducing it) rather than when there are
strangenesses in it. And using numbers that run top to bottom for one
half and bottom to top for the other just are again the kind of
weirdness I wanted to avoid with a different scheme in the first place.
> So the current \voice<n> becomes \voice<n%2 ? Up : Down><ceil(n/2)> ?
> Or \<ordinal>FromTop and \<ordinal>FromBottom?
Somewhat better. But I consider it somewhat inelegant if \twoFromBottom
is for bassoon I and \oneFromBottom for bassoon II.
That gets soon into the realm of "repulsive" that Dan called a mismatch
of voice numbers and style numbers.
>> So does
>>
>> << topmost \\ 2nd from top
>> \\ { \inner \inner \voiceDown topmost stem-down }
>> \\ middle stem-down \\ bottom stem-down
>>>>
>>
>> Basically you need to only fix those voices not obeying the standard
>> scheme (usually just one) and the rest will work out. So I don't really
>> think that a special syntax is needed.
>
> True. But isn't the point of this shortcut notation that it saves you
> the trouble of specifying those directions and voice names on your
> own?
Sure, but you talk about a case where one _has_ to specify a direction
and voice name after all because the default does not work. Admittedly,
yet another shortcut saves you from figuring out what level of \inner
(or whatever) you have to use.
> Coincidentally, that's why I hardly ever use it: I tend to get
> lost with the automatic assignment
Well, which is why the automatic assignment should be as predictable and
brainless and useful as possible.
I think that the proposal in its current form is significantly better
than what we started with. But obviously we don't want to have such
shakeups occur more often than absolutely necessary, so we should not
just get something that's better what we started with but also not worse
than anything else we can think of at the moment.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
