Menu
▾
▴
1 Attachments
#2783 wrong placement of timesignature
Verified
nobody
Critical
2012-10-19
2012-08-28
Anonymous
No
Originally created by: *anonymous
Originally created by: colingh...@gmail.com
Originally owned by: benko....@gmail.com
Gagi Petrovic reported here:
http://lists.gnu.org/archive/html/lilypond-user/2012-08/msg00645.html
---------------------------
Dear ponder, first of all: thank you for the newest version!
I noticed though, that since 2.16, the placement of TimeSignature is off in custom line-positions. I added an example to clarify this. Is this is bug or due to some new underlying mechanic?
Thank you!
Kind regards, Gagi
\version "2.16.0"
\relative c''{
\numericTimeSignature
c2 d \time 3/4 e2. \time 4/4
\stopStaff
\override Staff.StaffSymbol #'ledger-positions = #'(0)
\override Staff.StaffSymbol #'line-positions = #'(-4 4)
\startStaff
c2\rest c\rest [r1] \time 3/4 c2. c8 b a g f g
}
------------------------------
Discussion
Originally posted by: k-ohara5...@oco.net
This was intended, with commit 0b5d0acdc1 for issue 2553, but probably not desired.
The commit message gives the logic behind the change:
"the only non-standardness the old code catered for is altered line-count.
the aim here is to position time signature similarly with any of the following:
\override StaffSymbol #'line-count = #'4
\override StaffSymbol #'line-positions = #'(-2 0 2 4)
\override StaffSymbol #'line-positions = #'(-4 -2 0 2)"
The patch centers the time-signature around the staff-line nearest to the center of the staff.
Originally posted by: dak@gnu.org
It is not issue 2553 but rather issue 2533. Cf <URL:https://code.google.com/p/lilypond/issues/detail?id=2533#c73> and the comments it tries answering. I still consider the time signature moving in relation to the staff lines (unless shifted by the user who also is responsible for the irregular staff line layout) a mistake, and the example from this patch gives an excellent reason: the user has no predictable way of letting the time signature end up where it should.
It would likely make sense to revert this part of issue 2533, possibly adding a manual way of shifting the time signature (may already be available, but I have not checked).
Cc: benko....@gmail.com
Originally posted by: benko....@gmail.com
what about centering time signature by default to the centre of the staff regardless whether there be a staff line or not? that would make both Gagi's and mine example work, as well as being a simplification.
I agree that there must be a manual way of shifting; I'll take a closer look to the possibilities in the evening.
Originally posted by: k-ohara5...@oco.net
Revert 0b5d0acd first, because there is no other workaround for this problem.
Then maybe add a 'position property for TimeSignature, falling back to the old behavior based on 'line-count. Centering regardless of a staff-line at the center breaks the more common case of a 4-line staff.
Originally posted by: dak@gnu.org
I can't think of a 4-line staff that would be relevant here. I don't think either chant or tablature even have time signatures. I'll take a look whether the existing properties allow shifting, anyway.
Originally posted by: dak@gnu.org
\override Staff.TimeSignature #'Y-offset = 1
works just fine for juggling the vertical position of signatures around. So I'd say we just use the 0 position for the time signature, and leave the rest to the user. If he is defining irregular barlines, he'll know best where he wants the signature to end up.
Originally posted by: benko....@gmail.com
please, please, I'm a user as well: centre-of-staff or
line-nearest-to-centre-of-staff
are both better defaults than 0 for me; and, besides being a user,
I'm also a musician with about 30 years of experience. The staves I've seen
can be described in terms of 'line-positions as
(-4 -2 0 2 4) (normal staff)
(-6 -4 -2 0 2 4) or (-4 -2 0 2 4 6) (normal staff extended temporarily
instead of using ledger lines; six-line staves of 14th century Italian
music)
(-4 -2 0 2) or (-2 0 2 4) (four-line staves of plainchant)
(-4 0 4) (modern music using inexact pitches)
what I have never seen include
(-3 -1 1 3)
(-4 4)
of course that doesn't mean they don't exist, but if anybody has data that
they are more frequent than the ones above, please speak up.
p
Originally posted by: dak@gnu.org
Well, "centre-of-staff" does not really have a dependable definition for irregular stafflines, does it? "normal staff extended temporarily" would _definitely_ benefit from using 0 as a default as then the time signature would not move around when the staff is being extended.
Staff_symbol::line_positions calculates (-3 -1 1 3) for a 4-line staff and (-5 -3 -1 1 3 5) for a 6-line staff unless explicit line positions are given.
plainchant does not take time signatures as far as I know. For (-4 0 4), the 0 position does not seem unreasonable for the time signature.
I don't doubt your experience as a musician. I just don't follow the programmatic conclusions you draw from it.
Also as a programmer and user interface designer: if it is not possible to pick the correct solution 100% of the time, the next best thing is to pick a _predictable_ solution that can easily be adjusted. An override on Staff.TimeSignature #'Y-offset will do just that.
Originally posted by: benko....@gmail.com
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.
Originally posted by: dak@gnu.org
"marginal benefit": If the starting chord requires a temporal extension, or if we have a meter change during a temporal extension...
If you consider yourself a second-class citizen as a user submitting patches compared to a user submitting bug reports, please be aware that _every_ user using 2.16.0 is forced to use the semantics you have submitted, so you are actual the sovereign. Sovereignty comes with responsibility. In this case, it has been my responsibility to permit this patch series into 2.16.0. I had been considering reverting it in 2.16.0 right after submission, but decided against it in order not to discourage further contributions. So I placed your interests, or rather LilyPond's long-term interest of keeping you motivated in working on it, higher than those of the entire user base, with the consequence of having the largest user-visible regression (so far) we need to deal with in 2.16.1.
Which is what we are currently trying to do.
Now your submissions tend to conflate several different things into a single large patch, which makes reviewing them rather hard, and our usage of Rietveld, a single-patch bartering place, makes this an even worse idea. I am aware that we are still in the process of getting you acquainted with the workflow. It took quite a bit of work to at least have this patch split into separate pieces, and it turns out that this was a good idea since we now have the possibility of actually reverting only that part of the patch that turned out problematic.
Please note that "a single user reporting" an issue does not mean that only a single user _encounters_ an issue, so it does not mean that we take a single user as being more important than a developer, but the entire user base has a bit of weight. There are a number of developers who had a patch reverted when an immediate fix was not in sight. Even when it is, it sometimes makes for a cleaner slate to revert and refix. I think I had a (trivial) patch once reverted at least three times in a row because I did not get it right. And actually, it turned out that the final problem was elsewhere, but triggered by my patch.
Yes, "predictable solution" and "have to override" is a tradeoff. For (-4 2 0 2), there is no "staffline closest to center". Picking one is not predictable. A quite predictable and overridable solution that catches 90% of all use cases is preferable to me over an unpredictable one catching 95% of use cases because I don't know when I will have to tackle the remaining 5%, and how. And I don't know whether my 5% fix will stay valid. And there is no way one can create a sensible convert-ly rule for automatic conversion.
"If you are using irregular stafflines, LilyPond will place the time signature somewhere where it feels it makes sense. You have to check after the fact whether this is what you intended, and possibly move it relative to wherever it ended up being." is not something I want to write in a reference manual.
Yes, it might mean that one part of your contribution, one that you had put work and thought in, will not remain in LilyPond, and that is disappointing. Perhaps by discussing your plans more on the LilyPond list before submission, this might have been avoided. And perhaps not. Sometimes it takes actually following through with an idea to be able to judge its consequences.
We are working on LilyPond together, and I don't think anybody is trying to make it harder for others just out of spite.
Originally posted by: k-ohara5...@oco.net
The former code was in place for ten years, making LilyPond center the TimeSignature on staff-position 0 for staves with odd line-count, and on position 1 for staves with even line-count.
My copy of Ted Ross' book on music notation does differently, centering the time signature on staves with unusual line-count (like percussion staves) or for modern music moving the time signature clear above the staff.
It seems everyone can get what they want with the override David suggested
\override Staff.TimeSignature #'Y-offset = 2
Other people in addition to Gagi have probably used LilyPond with staves with unusual line-positions, and somehow got the Time Signature where they like it, and will upgrade to 2.16.x. It would be difficult to communicate to them the need to change Y-offset, so wiser to restore the old behavior.
This is just the usual thing to do when an attempted improvement to software causes an unforeseen change in a formerly-successful application of the software.
Originally posted by: dak@gnu.org
Is position 1 for even line-count preferable over position 0 in general? If there is agreement for that, we can keep this behavior for regular staves (though what about the case of 0 lines?), those with empty line-positions. If Ross is indicative, however, I think the "use 0" rule is easily understood and easily overridable, even though it would be incompatible with the old behavior in case of even regular line counts.
Originally posted by: dak@gnu.org
Regarding comment #9: try
git log --grep "This reverts"
and you'll see that reverts are a common part of our development process. You are in no way singled out here. And yes, you can do nothing wrong when reporting a bug properly (even if it turns out you have been mistaken), whereas you can do things wrong when fixing a bug. And part of the reason is that a bug report has no permanent effects (well, apart from social ones) that the reporter is responsible for, whereas a change to the code base has.
It is an unfairness every developer has to deal with, the price of having the power to affect every user's work for better or worse.
Originally posted by: benko....@gmail.com
well, yes and no. this code may have been in place for ten years, but
the meaning
of line_count changed with commit d10ec4f5 (sometime around 2.15.20 -
I don't have
the sources at hand, but see
https://code.google.com/p/lilypond/issues/detail?id=2109#c18
); as a consequence, a simple revert wouldn't make Gagi happy, I'm afraid.
(aside 1: I know nobody else bitten by this change of semantics of
Staff_symbol::line_count, as far as issues and regtests I've seen are
representative.
aside 2: the patch in issue 2109 caused issue 2249, where again revert
was suggested.
my problem is not reversion in itself, but unconsidered reversion.)
so what about using centre-of-staff, i.e. (min(line-positions) +
max(line-positions)) / 2?
is it worth preparing such a patch? note it will change behaviour
relative to 2.14 in the
case of overriding line-count, not line-positions.
p
Related
Issues:
#2109Originally posted by: dak@gnu.org
In the case without line-positions, centre-of-staff is strictly equivalent to position 0, except that it is undefined for line-count=0. The most common use for line-positions will likely be regular positions, but with an offset (like the additional staff lines you described). In that case it would seem most sensible to not move the time signature along with the staff centre: it seems pointless to use an offset if the time signature ignores it.
I have seen no argument regarding use of line-positions that looked preferable to using position #0 to me. The one thing I feel ambiguous about is when not having line-positions, and an even value of line-count. The "natural" cases, tablature and plainchant, don't call for a meter. LilyPond "historically" appears to use an offset of 1 for that case; there probably is an intention behind that, and revisiting that intention would make sense before trying changes here.
When we are talking about unusual staff arrangements, I don't think it unreasonable if the user (or provider of appropriate Staff context definitions) will also have to decide about the meter position, and "0" is very simple and straightforward as a starting point for that.
Picking something more diverse than that makes sense only in when there are well-established typesetting practices that LilyPond can recognize reliably from the input.
Originally posted by: benko....@gmail.com
I'm convinced and will create the patch.
p
Originally posted by: dak@gnu.org
While it will not make a difference with regard to Rietveld's single-diff review, when replacing a complex behavior with a simpler one, it might make sense to structure the commits into revert + additional change(s). That way the changes are easier to look at on their own. Particularly if it turns out that they cause new problems.
Yes, most of this discussion should have happened before. Attendance in reviews continues to be embarrassingly weak. It would probably already help a lot with code quality if some secret autobot posted "I don't understand what this is supposed to do" for every 10 lines of code without comment, and more people got drawn into the resulting fights.
With regard to the original time signature patch, I did express some bewilderment when reviewing the changes. I did not, however, seriously involve myself with the rationale of its design, and nobody else bothered either.
This is not optimal for our code quality, and it is also not optimal for the work atmosphere as it causes tensions when unnecessary work is done, and tensions when people start complaining violently about intended consequences of work that had been easily accessible in the review stage.
I'll try to figure out when the "even line-count" scenario got special-cased so that we can better estimate of how much sense it makes to retain that. Comment #11 would suggest that Ross provides some incentive to change to position 0, but of course it will cause a one-time inconvenience to everybody already relying on (or having compensated already) existing behavior. So we better make sure that if we are going for something else, we have solid reason not to change again later.
Thanks for bearing with our somewhat bumpy processes.
Originally posted by: benko....@gmail.com
Am I right in interpreting all this as "please don't touch it until said so?"
p
Originally posted by: dak@gnu.org
Or if you can beat me to finding the reason for the original design.
Originally posted by: dak@gnu.org
The origin of this change appears to be
commit [r9a38b47c4a4589f2e7c413fcdfff83de454719e6]
Author: Rune Zedeler <rune@lilypond.org>
Date: Wed Jul 31 06:42:48 2002 +0000
[...]
* lily/rest.cc:
* lily/time-signature.cc: spacing for even number of staff lines.
Which would appear to have been involved with the pitched rest positioning changes as well which took a lot of discussion until we arrived at a consistent solution as well if I remember correctly.
I'll try to see whether I can find any archived discussions about those changes at the time they were made.
Originally posted by: dak@gnu.org
The keyphrase of interest to us would likely be "mensural time signatures" (at least that is what appeared on the developer list at a time related to the change in 2002). It is conceivable that they constitute a "standard case" in connection with even line-count that we should be getting "right" without "additional" overrides.
Iff we choose to pick "0 for all", it might imply having to review the mensural staff definitions for the need of offsets.
This is all very hand-wavy.
Originally posted by: benko....@gmail.com
I've found (and referred to) those:
https://code.google.com/p/lilypond/issues/detail?id=2109
https://code.google.com/p/lilypond/issues/detail?id=2249
https://code.google.com/p/lilypond/issues/detail?id=2300
Related
Issues:
#2109Originally posted by: benko....@gmail.com
I found discussion about d10ec4f5:
https://code.google.com/p/lilypond/issues/detail?id=1193
https://code.google.com/p/lilypond/issues/detail?id=1972
Originally posted by: dak@gnu.org
Phooey. Mensural notation tends to have five lines (and that's the default in our staffs as well). There is reference to it being able to have six lines, but I find no examples. <URL:http://ieee.uwaterloo.ca/praetzel/mp3-cd/info/raybro/mensur.html> seems to suggest that time signatures tend to be shifted upwards in four-staff systems, but I have the suspicion that the images on that page are cropped at the top, losing lines.
Originally posted by: benko....@gmail.com
it's 14th century Italian music (e.g. Landini). I found one image which
may have a time signature (O2 in third staff from bottom on the right
hand side):
http://historyofinformation.com/images/squarcialupi_codex.jpg
I agree and anyway those are ugly prints. Petrucci's Odhecaton is available
on IMSLP and is much more beautiful example to follow.
time signatures in manuscripts have no fixed place and size
(in many cases they fit into a space),
so you shouldn't worry too much.