Menu
▾
▴
1 Attachments
#3242 Manual beaming over rests and vertical spacing problem
Originally created by: *anonymous
Originally created by: ma...@gregoriana.sk
Originally owned by: mts...@gmail.com
Reported by Clément:
http://lists.gnu.org/archive/html/bug-lilypond/2013-03/msg00054.html
Using oneVoice position (or indirectly, partcombineApart) while making a beam
go
over a rest destroys vertical alignment in a staff.
Here is a small example, with or without manual beaming over the rest.
%%%
\version "2.17.13"
\relative c'' {
\voiceOne \dynamicUp f4\fz f8 f f[ [r16] f] f8 f |
\override DynamicText #'X-offset = #-3 f4\fz f8 f f[ [r16] f] f8 f | \mark
\default
}
\relative c'' {
\voiceOne \dynamicUp f4\fz f8 f f [r16] f f8 f |
\override DynamicText #'X-offset = #-3 f4\fz f8 f f [r16] f f8 f | \mark
\default
}
%%%
Overriding outside-staff-priority or Y-offset is uneffective.
It also affects BarNumber's vertical position.
I encountered this bug while updating a score from an older version of
lilypond,
but I cannot remember which one exactly. I think it was 2.16.
Originally posted by: ma...@gregoriana.sk
This happens since 2.17.10 but not in 2.17.9
Originally posted by: dak@gnu.org
Looking through all relevant commits, I don't see anything even remotely as likely (judging from the commit message) to be the culprit as:
commit [r7d3d28de0ce6e2f018aff599cecd944d1754fe3c]
Author: Mike Solomon <mike@apollinemike.com>
Date: Thu Jan 10 08:54:12 2013 +0100
Makes all side-positioning based on skylines instead of boxes.
The major work is in side-position-interface.cc, with minor
modifications at several places in the code-base to adapt to this.
This allows for snugger positioning of horizontally-oriented
fingerings.
A side-effect of this patch is that side-positioning of all
cross-staff grobs delves into the element list of axis-groups
in order to better guess position, which results in less
collisions (for example, dynamics are less likely to collide
with cross-staff beams).
So it would probably make sense to check this one for introducing the problematic change.
Originally posted by: m...@mikesolomon.org
The problem seems to be within the skyline constructor in skyline.cc on line 529 (the one that takes a vector of Skyline_pairs). A bunch of valid skyline pairs are passed into it and out is spit a flat skyline that the dynamic aligns to. The skyline's plateau point is the beam.
Originally posted by: m...@mikesolomon.org
Sorry, meant to add that this happens on line 905 of axis-group-interface.cc in the creation of inside_staff_skylines.
Originally posted by: dak@gnu.org
The code is such a flamboyant piece of crapola that it is hard to even guess where the problem occurs. It pushes a number of skylines into a deque, then pops two elements from the front, merges them, and pushed them back into its rear. And when it is finished, it does
buildings_.swap (partials.front ().buildings_);
Why swap? Makes no sense at all. Similar the use of splice elsewhere.
That's all quite loopy. However, what probably takes the cake, platter, and all is Skyline::normalize. The wobbly things that it does with iterators do not make any sense at all. Its original last_empty setting tries to ensure that it does not step backwards out of the array in the first iteration, but if the conditional triggers in the second and third iteration, it still stomps backwards out of the array.
Naturally, all of those exciting and inventive ways of juggling with data don't come with any comments explaining the particular non-boring implementation choices and the underlying intent.
Originally posted by: k-ohara5...@oco.net
Notice that the problem depends on having a beam over a rest.
Workaround:
\override Stem #'stemlet-length = #0.5
The Rest has a Stem data structure, but if we do not ask for any stemlet, that Stem has empty extent. The patch for issue 2527 treats an empty extent as an infinitely large extent.
Re: comment 3, could one of those valid skylines been an infinitely-wide skyline from the empty Stem of the Rest?
Originally posted by: mts...@gmail.com
Gives invisible stems point extents.
http://codereview.appspot.com/7762049
Labels: Patch-new
Owner: mts...@gmail.com
Status: Started
Originally posted by: mts...@gmail.com
Creates more possibilities for vertical and horizontal skyline functions.
Allows for skylines that use a flat horizon for certain problematic grobs.
http://codereview.appspot.com/7516048
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make test and a full make doc.
Labels: -Patch-new Patch-review
Originally posted by: mts...@gmail.com
Response to Keith's comments
http://codereview.appspot.com/7516048
Labels: -Patch-review Patch-new
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make test and a full make doc.
Reg test diff attached
Labels: -Patch-new Patch-review
Originally posted by: mts...@gmail.com
Removes evil code from C++, replaces with happy defaults in Scheme
http://codereview.appspot.com/7516048
Labels: -Patch-review Patch-new
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make test and a full make doc.
Reg test diff attached
Labels: -Patch-new Patch-review
Originally posted by: mts...@gmail.com
Adds comments
http://codereview.appspot.com/7516048
Labels: -Patch-review Patch-new
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make test and a full make doc.
Reg test diff attached
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Patch on countdown for 23 March - 12:00 GMT
Labels: -Patch-review Patch-countdown
Originally posted by: pkx1...@gmail.com
Patch counted down - please push
Labels: -Patch-countdown Patch-push
Originally posted by: mts...@gmail.com
Pushed as [r7b2cb93fc69c7d7c45f0ae6495f688752efeb107].
Labels: -Patch-push Fixed_2_17_15
Status: Fixed
Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified