Re: [Lilypond-auto] Issue 2783 in lilypond: wrong placement of timesignature

[lilypond]

Comment #9 on issue 2783 by address@hidden: wrong placement of  
timesignature
http://code.google.com/p/lilypond/issues/detail?id=2783

ok, I actually use centre-of-staff-range, i.e. (min + max) / 2, so all of
(-4 4) (-4 2.5 3 3.5 4) (-4 -2 0 2 4) has centre 0.

well, yes, but the benefit is marginal as generally there's no time  
signature
within a temporary extension.

I know; my claim is that existing 14th century 4-line staves correspond
not to
\override #'line-count = #4
but to
\override #'line-positions = #'(-2 0 2 4) % (-4 -2 0 2)
I base that claim on clefs (generally c-clefs), which are invariably on a  
line,
never in a space.  you may say that a clef is anchored to the staff which
I just destroyed with the \override, but I see a clef anchored to a line of  
the
theoretically infinite staff of which only a finite segment is shown.

actually that's why I tried to come up with solutions that do not favour
overriding line-count over overriding line-positions.

I agree; incidentally both of my suggested defaults evaluate to 0 in this  
case.
the original report has the case (-4 4) which I see rather like the
dot placement of the repeat sign: if a space in the middle of the staff can
hold the whole time signature, put the whole thing there.  (now _that_ does
make prediction harder, but if it corresponds to real world usage, I'm happy
to implement it.)

consider it whining.  to put it otherwise: I sometimes feel myself, a user
submitting patches, regarded as a second-class citizen compared to one
submitting bug reports and feature requests, though I really take care to
create patches that do not favour my pet projects over all the scores I  
know,
including regtests (even if I consider some of them impractical).

remember that my first patch to issue 2533 was reverted (quite abruptly to  
me).
at that time it hurt me that that single user reporting issue 2648 was
more important than me (i.e. such a fix was chosen that unfixes my problem),
but I also conceded that his case is general and important enough, I've  
seen it
in several scores, so I worked on a fix that addresses his concerns too.
in this case I'd like to see more data that reverting or modifying that  
commit
is better than suggesting to the reporter to override Y-offset.

there's a tradeoff between "predictable solution" and "have to override".
centre-of-staff is almost as easily predicted as 0, and needs no override in
all the cases I know, including the original one in this thread.