Re: fix representation switching from line-position to staff-space (issue 6778050)

[Benkő Pál]

2012/10/30 David Kastrup <address@hidden>:
> Benkő Pál <address@hidden> writes:
>
>> 2012/10/27  <address@hidden>:
>>> On 2012/10/27 20:34:35, benko.pal wrote:
>>>
>>>> I want staves with line-positions like (-2 0 2 4) work.
>>
>>> Why would somebody specify (-2 0 2 4) with the expectation that the
>>> results should be identical to (-3 -1 1 3)?  Why would he not specify
>>> (-3 -1 1 3) in the first place then?  How is something "working" when
>>> it nullifies what the user is trying to do?
>>
>> clefs: when specifying (-4 -2 0 2), you can use \clef alto or similar
>> to get a c-clef on the third line.  in other words: when I want to
>> LilyPond-ize ancient music using four- or six-line staff, the expected
>> representation is a standard staff reduced or expanded by a line.
>
> And?  Why would looking at the line_count property then yield a wrong
> result?  You are specifying a missing line in the line positions, but
> the overriden line count would still lead to the same positioning of
> clefs.  Which would be exactly what was wanted.

sorry, David, I'm lost.  (-4 -2 0 2) and (-3 -1 1 3) yield different alto clefs,
I expect that, and that's why I prefer overriding line-positions to line-count.

>> I may well imagine that for some drumming applications the best
>> choice is a staff spaced by three, e.g. (-4 -1 2 5), because this way
>> every pitch in the range used is unambiguously assigned to a staff
>> line.
>
> A drum staff is not exactly going to need an alto clef.  Or a
> divisioMaior line.

agreed.  I meant this to be an independent argument to handle
asymmetric staves more gracefully, as such staves may need
rests, time signatures, repeat signs, slurs, and those would look
best like in tablature (= a staff with staff-space = 1.5).  this patch
is an independent element of a set of several such patches.
(it started as one patch, then got reverted as a whole.)

> I really have a hard time seeing just _what_ improvements we get over
> the 2.14 behavior.  Is there any _real_ _existing_ problem that now
> works better than before?

I never use divisioMaior, so can't speak about that.
I had real existing problems with rests which launched
me on this crusade against line_count a year ago.
time signatures don't work the 2.14 way, as you admitted in
http://code.google.com/p/lilypond/issues/detail?id=2783#c35

p