Menu
▾
▴
1 Attachments
#1713 Whole note/dotted note collision in polyphony
Originally created by: *anonymous
Originally created by: ColinPKC...@gmail.com
Originally owned by: k-ohara5...@oco.net
Reported by Connor Harris:
\version "2.14.1"
%{ When whole notes and shorter notes are in polyphony, they normally appear as
in the measure on the left. With dotted notes, though, LilyPond moves the
shorter note to the right of the whole note, but not far enough, causing a
collision. %}
<< {d'2 s2 d'2.} \\ {d'1 d'1}>>
Note: this may be related to issue 1546, Breve collides with noteheads in other voices?
Originally posted by: connor...@gmail.com
For what it's worth, the same problem appears with up-stemmed notes, and when the notes are a step apart, LilyPond gets the horizontal spacing right.
\version "2.14.1"
<< { c''2. s4 c''2.} \\ {c''1 b'1} >>
- Connor Harris
Originally posted by: brownian.box@gmail.com
This may be related to Issue 1546.
Related
Issues:
#1546Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Labels: -type-Collision Type-Ugly
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Labels: -Priority-High
Originally posted by: janek.li...@gmail.com
(No comment was entered for this change.)
Owner: janek.li...@gmail.com
Status: Started
Originally posted by: janek.li...@gmail.com
(No comment was entered for this change.)
Owner: ---
Originally posted by: plros...@gmail.com
Dots are not essential for the problem. In this case, Lilypond decides to put a chord of wholes on the left. In the second measure, the notes have different pitch, yet they collide.
<< { e'2 s2 e'2 s2 } \\ { <d' e'>1 <d' f'>1 } >>
Originally posted by: k-ohara5...@oco.net
Have you started yet, Janek ?
I see the problem. The horizontal shifts are scaled with the width of the down-stem note-head. [Edit: Well, these examples with whole notes don't seem to scale with the down-stem note-width, because the fix to issue 53 layered another set of correction factors on top of that for the special case of whole notes.]
The shift should, however, be proportional to the width of the note-head that ends up on the left (because the reference points for note-heads are on their left). (Better still to use the sum of extents between the reference points.)
I see a path to fix this and issue 1546, and issue 53 (which has become re-broken).
Related
Issues:
#1546Issues:
#53Originally posted by: janek.li...@gmail.com
Keith,
you are right with your diagnosis.
As for my involvement, here's the situation:
- i tried to solve this together with Łukasz, but we got stuck on reading the code
- Łukasz discussed for_UP_and_DOWN macro and some other things for several weeks
- meanwhile, David started to work on this, but he decided to wait until Łukasz finishes.
So i guess that you should contact David, as he may resume his work now.
Cc: dak@gnu.org
Originally posted by: k-ohara5...@oco.net
Patch for this and issue 1546 is expected to change many regression tests.
Several cases of simultaneous chords should be closer when a smaller note is placed to the left of a wider one, and further when the wider note is at left.
collision-whole.ly -- will show this bug being fixed
part-combine.ly dot-column-engraver.ly partcombine-midi.ly collision-merge-differently-headed.ly collision-dots-invert.ly -- a bit more gap between chords
collision-dots.ly collision-heads.ly -- more uniform gaps
collision-2.ly collision-harmonic-no-dots.ly -- a bit less gap
http://codereview.appspot.com/6189048/
Delaying review because some follow-up to the comment https://code.google.com/p/lilypond/issues/detail?id=984#c10 might be in the works.
Labels: Patch-needs_work
Related
Issues:
#1546Issues: #984
Originally posted by: dak@gnu.org
Currently no followup to the given comment in the works. Am currently focused on other stuff, and the work I started on issue 984 is far enough from completion that it does not make sense to hold up other stuff for it.
Related
Issues: #984
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Labels: -Patch-needs_work Patch-new
Cc: -dak@gnu.org
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: LGTM.
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Owner: k-ohara5...@oco.net
Originally posted by: ColinPKC...@gmail.com
Counted down to 20120508, please push.
Labels: -Patch-countdown Patch-push
Originally posted by: k-ohara5...@oco.net
On my final check I noticed that this slightly over-corrects one situation in issue 1546.
The same code covers both issues, so the code history will more clear if I fix both in one commit. This new patch does so, with the same desired changes in the regression tests, as listed in comment 12 above.
http://codereview.appspot.com/6189048/
Labels: -Patch-push Patch-new
Related
Issues:
#1546Originally posted by: pkx1...@gmail.com
Patchy the autobot says: LGTM.
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
More special treatment of breves, for the issue 1546 aspect of the patch.
When they are one step apart in pitch, round notes can get closer; breves cannot.
http://codereview.appspot.com/6189048/
Labels: -Patch-review Patch-new
Related
Issues:
#1546Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: LGTM. but several regtests show slight changes, unnoticable to me.
Labels: -Patch-new Patch-review
Originally posted by: plros...@gmail.com
The patch removes several constants (1.25, 1.35, 0.7 and 0.75) and replaces them with some generic formula. It may be a great thing for other projects, but I don't think it's a good approach for Lilypond. The constants are based on a human choice of what is "just right" for the distance between notes. Those numbers may be later made available for tweaking. A generic algorithm makes it harder to tweak one distance without tweaking other distances.
I believe there should be no slight changes. The new code should provide exactly the same distances for the cases not affected by the bug.
I don't think we have a good test for collisions. We need a big test, a matrix with all combinations of notes that can collide. That should cover all styles, all standard shapes of noteheads, all durations and all pitch differences.
Such test might find new problems, which is OK. They would be outside the scope of this patch. However, the differences in the output should be checked for regressions.
Originally posted by: k-ohara5...@oco.net
Each of the constants (1.25, 1.35, 0.7 and 0.75) handles a specific combination of note durations, and the block of code is used only when voices have notes at the same pitch. So the cases are the four measures in
\relative c'' << { c1 c1 c2 c2 c4 c4 c4 c4} \\ { c2 c2 c4 c4 c4 c4 c1 c1} >>
plus collisions with chords where both chords contain a common pitch.
The slight changes are described in comment 12. I think there is another reg-test change with the last patch, for wholes in the situation of comment 20, but I didn't write down which one. I'll summarize after I next run the tests.
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Labels: -Patch-waiting Patch-needs_work
Originally posted by: k-ohara5...@oco.net
Expect changes in the same set of regtests as listed in comment 12:
part-combine dot-column-engraver test-output-distance collision-whole collision-dots partcombine-midi collision-dots-invert collision-heads collision-2 collision-harmonic-no-dots collision-merge-differently-headed
New patch expands the regtest collision-whole to include the situation from comment 20.
plroskin seems to have graciously offered in comment 22 to check that these expected changes are in fact desried changes.
http://codereview.appspot.com/6189048/
Labels: -Patch-needs_work Patch-new
Cc: p...@Gmail.com
Originally posted by: pkx1...@gmail.com
Patchy says LGTM. Attached redesigned reg test..
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
I had intended to put up the image of the cases where the constants (1.25, 1.35, 0.7 and 0.75) were applied.
\relative c'' << { c1 c1 c2 c2 c4 c4 c4 c4} \\ { c2 c2 c4 c4 c4 c4 c1 c1} >>
The constants appeared in the patch to issue 53, as correction factors for when colliding notes have different widths. If chords or dots cause a different left-to-right order of the notes, however, we need different correction factors. I am too lazy to compute factors for the full matrix of possible cases, and to test them against all note head styles and fonts.
The old factors do not look "just right" anyway, so I am happy to take the generic algorithm.
Related
Issues:
#53