Menu
▾
▴
#1618 unpredictable placement of rests
Originally created by: *anonymous
Originally created by: percival.music.ca@gmail.com
This is split from issue 1609 (that issue was specifically about the problem we saw in partcombine-midi.ly)
As the examples below illustrate, placement of such rests still changes unpredictably. The score in example 2 produces different output with the two command lines
lilypond test.ly
lilypond test.ly test.ly
while version 2.12.3 produces the same output in either case. Both versions produce a warning "too many colliding rests". See also issue 1547 and issue 384.
The variation in position of the rests appeared somewhere between 2.13.48 and .54
The completion- engravers are not essential, it is simply the fact that LilyPond does not have a rule to place simultaneous rests with a note of different durations (see issue 1547). Smaller example, which produces different output depending on whether the file is alone on the command line or second in a list of .ly files:
\version "2.12.3"
\new Staff <<
\new Voice {
\voiceOne
[r1] [r1]
}
\new Voice {
\voiceThree
c'2 e' g' b'
}
\new Voice {
\voiceTwo
[r1] [r1]
}
>>
Related
Issues: #1547
Issues: #1609
Issues: #384
Originally posted by: percival.music.ca@gmail.com
I think it happened earlier than 2.13.48 -- maybe even before 2.12 or 2.10, meaning that it's not Critical. I tried to do a bisect, but I ended up looking at a doc translation merge that had nothing to do with code at all!
It's really unfortunate that we can't run valgrind on lilypond; it's great for finding the use of uninitalized variables. Does anybody have any other favorite static code analysis tool which can identify uninitalized variables?
(the alternative is to spend half an hour seriously looking at variables in the relevant part of the source code; I may give that a shot if nobody has any other suggestions before tomorrow)
Originally posted by: k-ohara5...@oco.net
Quite possibly the problem existed in 2.13.48, and my testing missed it. Testing for inconsistent output is difficult, because the inconsistent output is sometimes by chance consistent.
Other reasons to make this non-critical are:
1) it occurs only in complicated cases where LilyPond needs the user's help, probably substitution skips or pitched rests, to produce easily-readable output, as logged in issue 1547 and issue 384.
2) LilyPond issues a collision warning referring to rests that have the inconsistent output. So even if output consistent with 2.12, it was only consistently /good/ by accident.
I don't know any approach better than debug printf()s in rest-collision-engraver.cc. This issue looks very much like issue 1031.
Labels: -Priority-Critical Priority-High
Originally posted by: percival.music.ca@gmail.com
I'm happy with this rationale.
Another note on valgrind: you _can_ use valgrind on lilypond, but in addition to all the memory errors it finds with guile (I'm not claiming that all these errors are *valid*, merely that valgrind reports errors), it also finds tons of uninitalized variables in guile. If guile was really _that_ full of uninitalized variables, then I can't see how it works at all... but guile clearly _does_ work, so I suspect that valgrind simply doesn't understand how guile sets up variables internally, and thus it's not useful.
Adding suppression files (for example, generating a suppression file from running lilypond with no arguments or files, then using that suppression file when generating the example in question) doesn't help. I only see a few instances of uninitalized variables, but these are all buried deep in the guile library.
Originally posted by: k-ohara5...@oco.net
The problem is that rest-collision takes an array of rests, but handles *only* the first rest in the array. The order of rests in the array is inconsistent (which I do not believe is a problem in itself).
Patch with a clean make check is attached; it will be on the rietveld server if and when I resolve an issue with my internet service. I'm still thinking about what could serve as a regtest.
Labels: Patch-new
Originally posted by: percival.music.ca@gmail.com
Amazing work as always. I can confirm the clean regtests, and I've uploaded the patch here:
http://codereview.appspot.com/4441066/
Originally posted by: k-ohara5...@oco.net
I resolved my connection problem, and uploaded the patch and a regtest at
http://codereview.appspot.com/4442083/
The patch resolves both this issue and issue 1547.
Labels: -Patch-new Patch-review
Related
Issues:
#1547Originally posted by: k-ohara5...@oco.net
patch pushed in 1edd0
Labels: -Patch-review fixed_2_15_0
Status: Fixed
Originally posted by: PhilEHol...@googlemail.com
(No comment was entered for this change.)
Status: Verified
Originally posted by: Carl.D.S...@gmail.com
Backported
Labels: fixed_2_14_2