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

[Marc Hohl]

Am 30.08.2012 15:05, schrieb address@hidden:
> 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).
The comparison between users working on patches and bug submitters may 
be a bit
harsh, but I think I see the point.

In my opinion, some rather strange (or say: uncommon) areas of what lilypond
is capable in typesetting are difficult to handle for most of the developers
(no pun intended).

Moreover, it is sometimes not very easy to explain in detail the 
"philosophy" behind
a patch. At least I sometimes feel very unhappy about being not able to 
formulate
my ideas quite well, since my english is not as good as my ideas 
(hopefully) are.

On the other hand, reverting is the easiest thing to do when something 
just goes
wrong; so I think there is no-one to blaim here; it is just that there 
is not enough
time, not enough developers, not enough understanding of what you want 
to archieve.
Perhaps it would be better to have the time to exchange ideas first 
before reverting
a patch, but still ...

I hope that your experiences are not too frustrating for you. There are 
not as many
developers as lilypond deserves, so we need you. And perhaps there will 
be some more
time for a quick exchange of ideas when a patch went (partially) wrong 
before
reverting it; it may be that the expectations are wrong and the patch is 
correct, or
something in between.

Just my 2 ct

Marc


> 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.