Menu
▾
▴
#3363 Scripts misplaced with cross-staff slurs
Originally created by: *anonymous
Originally created by: k-ohara5...@oco.net
Originally owned by: k-ohara5...@oco.net
% Script (staccato in the example) is shifted by the staff-staff-spacing
% when it is set to go 'inside the cross-staff slur.
% If you remove the slur, the Script moves to the correct place.
% Bug first appears in 2.17.10
% Similar to issue 3327, but not solved by the patch there
% Workaround: \override Script #'avoid-slur = #'around
<<
\new Staff = "R" { s2 }
\new Staff = "L" {
\new Voice {
\voiceTwo
f'8 \change Staff="R" f'( \change Staff="L" f'_. f')
}
}
>>
Originally posted by: k-ohara5...@oco.net
This went wrong with commit [r7d3d28de0ce6e2f018aff599cecd944d1754fe3c]
Makes all side-positioning based on skylines instead of boxes.
for issue 2527: finger-flag collision
Originally posted by: m...@mikesolomon.org
Yikes...sorry!
I may not have time to work on this until May 28th but I'll get to it then if no one else does.
Originally posted by: k-ohara5...@oco.net
http://codereview.appspot.com/9426044
Labels: Patch-new
Status: Started
Originally posted by: pkx1...@gmail.com
Passes Make and Make check (not done a full make doc). Reg test diff attached
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Patch on countdown for May 19 - 06:00 GMT
Labels: -Patch-review Patch-countdown
Owner: k-ohara5...@oco.net
Originally posted by: pkx1...@gmail.com
Patch Counted Down - please push
Labels: -Patch-countdown Patch-push
Originally posted by: k-ohara5...@oco.net
commit [r1c893a4e3651018adcc13ea2c8f1c19b19faa722]
Labels: -Patch-push Fixed_2_17_19
Status: Fixed
Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified
Originally posted by: k-ohara5...@oco.net
unfixed, because placing the objects using the final position of the beam forced the beam to be set prematurely and issue 3385.
Labels: -Fixed_2_17_19
Owner: ---
Status: Accepted
Originally posted by: dak@gnu.org
Given the damage that the fix to issue 2527 is causing (it is also responsible for issue 3465), that it causes multiple problems, some of them critical regressions, that attempts to fix them lead to followup problems and that Mike (see comment #2) does not appear to have time to work on fixing the problems caused by the issue 2527 fix, shouldn't we bite the bullet and revert that commit including all unsuccessful attempts to address its followup problems?
Cc: mts...@gmail.com
Originally posted by: m...@mikesolomon.org
I'm guessing that an approach similar to http://codereview.appspot.com/12857043 would work here. To calculate Vertical Axis Group skylines, we ignore cross-staff grobs. The same should be true for grobs supported by cross-staff grobs.
A big problem we've been having is in defining terms. The staccato is surely not cross-staff, but it depends on cross-staff grobs. If a function can find these dependencies, we can filter these out when need be.
Originally posted by: dak@gnu.org
Well, "defining terms" is not really useful if the underlying concepts don't match realities. We have pure/unpure as independent/dependent from linebreaking, and crossstaff as we-can't-really-decide from linebreaking. But something like a staccato dot could not care less about linebreaking: it depends on the material it references. We are not doing ourselves in expressing every dependency in terms of before/after linebreaking. In particular since there are things like linebreaking depending on accidentals, and accidentals can depend on linebreaking again (a tied note gets a repeat accidental only after a line break).
This won't help us for this issue, but it might make sense for things like staccato dots to inherit their cross-staff property from their x-parent (assuming that the actual note is marked as cross-staff). Do we really need to know this for staccato dots?
Originally posted by: k-ohara5...@oco.net
"A big problem we've been having is in defining terms. The staccato is surely not cross-staff, but it depends on cross-staff grobs."
The staccato has been marked 'cross-staff' for a long time by ly:script-interface::calc-cross-staff, and the patch Mike wrote for the related issue 3327 would mark the staccato 'cross-staff' for other reasons that seemed logical at the time.
We were building consensus for a definition "cross-staff: true for objects whose placement relative to their parent Staff (or Lyrics, etc.) depends on the spacing of staves on the page."
The problem here seems to be that the pure-height of the stem with the staccato is miscalculated in stem.cc. It seems that the second stem's height should be calculated relative to the upper staff, but instead the third stem's height is calculated as if its note was on the upper staff. This problem does not seem to be due to the timing of iterators, but rather due to the order and way in which pure-height functions call each other during layout.
The various internal flags 'calc_beam' 'pure' 'cross_staff' are trying to organize the order of layout decisions, but it is not clear how. It seems to me that this staccato should recuse itself from influencing staff-spacing ("sorry, I'm cross-staff, I don't know what space I need just yet, I can give you my 'pure-height' as an estimate") but then when cross-staff items are being placed, fell free to trigger the final decision of the Stem and Beam.
Currently, the staccato asks for only the pure-height of the Stem, and that pure-height happens to be a spectacularly bad estimate.
Originally posted by: mts...@gmail.com
Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream
http://codereview.appspot.com/12951044
Labels: Patch-new
Owner: mts...@gmail.com
Status: Started
Originally posted by: m...@mikesolomon.org
Also fixes 3385.
Originally posted by: mts...@gmail.com
Changes comments
http://codereview.appspot.com/12951044
Originally posted by: pkx1...@gmail.com
Passes make, make check and a full make doc.
Reg test attached
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Patchy the autobot says: Two programming errors in input/regression/dynamics-avoid-cross-staff-stem-2.log disappear, which is nice. However, in input/regression/dynamics-avoid-cross-staff-stem.ly the fff and the p for the lower system are smashed into each other.
Labels: -Patch-review Patch-needs_work
Originally posted by: k-ohara5...@oco.net
The patch from comment 3, amended to avoid issue 3385
http://codereview.appspot.com/9426044/
Labels: -Patch-needs_work Patch-new
Owner: k-ohara5...@oco.net
Originally posted by: pkx1...@gmail.com
Passed Make, make check and full make doc.
Reg test diff attached
Labels: -Patch-new Patch-review
Originally posted by: mts...@gmail.com
Looks very good to me - great work!
Originally posted by: dak@gnu.org
The slur is apparently not in the metrics for the complete system. Shouldn't it get space in the unpure calculations?
Originally posted by: k-ohara5...@oco.net
Cross-staff things like that slur do not get considered for the size of the preview bounding box, issue 2968. Note-heads expand the box, I'll lower the C to a B in the regression test file so it shows the whole slur.
Originally posted by: pkx1...@gmail.com
Patch on countdown for August 21 - 06:00 GMT
Labels: -Patch-review Patch-countdown
Originally posted by: pkx1...@gmail.com
Patch counted down - please push
Labels: -Patch-countdown Patch-push