LilyIssues / Issues / #621 Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc)

Google Importer - 2010-11-19

Originally posted by: PhilEHol...@googlemail.com

Image added

621.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-11

Originally posted by: markpole...@gmail.com

I'm adding the phrase "DynamicText SpanBar collision" to
this post so others can find this issue with a search.

Jay Anderson kindly provided two workarounds (see below),
but these are not general solutions.

I propose adding a user-backend-property called
#'spanbar-padding to work in the X direction in the same way
that the #'staff-padding property works in the Y direction.
Would that be a good way to do it, and if so, how feasible
is it?

Thanks.
- Mark

Jay's workarounds:

1. Use whiteout and some padding:

whitePPPMarkup = \markup { \whiteout \pad-markup #0.5 \dynamic ppp } whitePPP = #(make-dynamic-script whitePPPMarkup) \new StaffGroup \relative f' << \new Staff { r1 | f2\whitePPP r | } \new Staff { r1 | f1 | } >>

2. Left align the dynamic with some offset

\new StaffGroup \relative f' << \new Staff { r1 | \once \override Staff.DynamicText #'self-alignment-X = #LEFT \once \override Staff.DynamicText #'X-offset = #'-1.25 f2\ppp r | } \new Staff { r1 | f1 | } >>

Last edit: Simon Albrecht 2015-09-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-02-05

Originally posted by: k-ohara5...@oco.net

If we want dynamics to get the space they need when notes are placed relative to barlines, then we can say
\override Score.DynamicText #'extra-spacing-width = ##f

By default, DynamicText has an extra-spacing-width that tells the note-spacing to ignore Dynamics (analogous to \textLengthOff). That way DynamicText items let the notes (and barlines) go where they like, and then DynamicText shift vertically when required. We can remove that default behavior with the override above.

Last edit: Simon Albrecht 2015-09-21

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-15

Originally posted by: k-ohara5...@oco.net

It is very tempting to make
\override DynamicText #'extra-spacing-width = #'(-0.5 . 0.5)
be the new default. I have been happily using this, and the regression tests are not harmed by the change.

We would need to rewrite the end of Learning Manual section 4.3.3 "Tweaking output" because it uses essentially this issue as the example needing to be tweaked !

Labels: Patch-review

Last edit: Simon Albrecht 2015-09-21

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-16

Originally posted by: perpeduu...@gmail.com

+1 for the extra-spacing-width, although it sounds more like a workaround.

Can this be related to issue #910?

Related

Issues: ~~#910~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-16

Originally posted by: k-ohara5...@oco.net

> although it sounds more like a workaround.

Well, the purpose of 'extra-spacing-width' is to specify how much space to allow for the item when spacing columns of notes. The current default for DynamicText says "don't allow any horizontal space at all for me; I will move vertically to make room" but that strategy does not work for bar-lines.

Issue 910 is a little related, but I should probably be solved a different way.

Related

Issues: ~~#910~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-16

Originally posted by: k-ohara5...@oco.net

(No comment was entered for this change.)

Labels: -Patch-review
Status: Started

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-24

Originally posted by: k-ohara5...@oco.net

Patch at http://codereview.appspot.com/4805054/

Regression test suite shows the expected changes: dynamic text spreads the line horizontally when they need the room.

After-patch output from midi-dynamics.ly (attached) might be interesting for what does *not* change. The decrescendo ends on the note that has the pppp, and the hairpin is shortened to fit between the dynamic marks (just like before). The next crescendo starts on the note *after* the one with the pppp, so it is drawn to that note, and must be lowered.

Spacing of hairpins, and of dynamic text spanners like cresc., does not change.

midi-dynamics.preview.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-25

Originally posted by: k-ohara5...@oco.net

(No comment was entered for this change.)

Labels: Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-25

Originally posted by: pkx1...@gmail.com

Passes Make and reg tests show minor changes (see attached)

Labels: -Patch-new Patch-review
Owner: k-ohara5...@oco.net
Cc: v.villenave

Screenshot1.png

Screenshot2.png

Screenshot3.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-29

Originally posted by: k-ohara5...@oco.net

One argument against having Lilypond make space for dynamic marks, is that hand engravers do not let dynamics influence note spacing.

It is always better to off-center the dynamics from their note, or make a gap in the bar line (Jay's workarounds from comment 2). I don't see how Lilypond can do this on her own but the workarounds got a bit easier:

\new StaffGroup << \override Score.DynamicText #'whiteout = ##t { c'1 c'4\fff c'2 c'8 c'\ppp \once\override StaffGroup.DynamicText #'X-offset = #-1 c'4\fff c'2 c'8 \once\override StaffGroup.DynamicText #'X-offset = #-2.5 g'8\ppp } { c'1 c'4\fff c'2-> c'8 c'\ppp | c'4\fff c'2-> c'8 c'8\ppp } r1*3 >>

Labels: -Patch-review
Status: Accepted

Last edit: Simon Albrecht 2015-09-21

workaround.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-07-29

Originally posted by: k-ohara5...@oco.net

(No comment was entered for this change.)

Owner: ---

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-08-17

Originally posted by: k-ohara5...@oco.net

Issue 631 has been merged into this issue.

Related

Issues: ~~#631~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-08-20

Originally posted by: percival.music.ca@gmail.com

(No comment was entered for this change.)

Labels: -type-Collision Type-Ugly

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2011-10-19

Originally posted by: kie...@alumni.rice.edu

This is true of arpeggios as well. Currently, piano-centered dynamics collide with arpeggios.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-01-27

Originally posted by: k-ohara5...@oco.net

Issue 2259 has been merged into this issue.

Related

Issues: ~~#2259~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-23

Originally posted by: dak@gnu.org

Well, this is butt-ugly. I propose that we use at least \override DynamicText.extra-spacing-width = ##f for those staff grouping contexts that have span bars. They are clearly looking bad. The argument "human typesetters don't adjust the spacing for dynamics" doesn't count as long as we don't have flexible placement of dynamics. Human typesetters will let the dynamics be a bit non-centered in order to avoid crossing the span bars.

Labels: -Priority-Medium

Last edit: Simon Albrecht 2015-09-21

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-26

Originally posted by: dak@gnu.org

Issue 621: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc)

Dynamics usually have extra-spacing-width set to an empty interval so
that their placement does not cause other elements to shift.

With span bars, however, the resulting overlap is a worse cure than
the problem. So this switches off the width-hiding setting of
extra-spacing-width inside of staff groups using span bars by default.
No extra space is allocated, so dynamics will clear the span bars only
narrowly, a reasonable compromise.

http://codereview.appspot.com/43210046

Labels: Patch-new
Owner: dak@gnu.org
Status: Started

Related

Issues: #621

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-26

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests. Two regtests are improved. The second one only accidentally. Maybe we should revisit the extra-width setting independently of span bars?

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-26

Originally posted by: dak@gnu.org

(No comment was entered for this change.)

621.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-26

Originally posted by: pkx1...@gmail.com

Patchy the autobot says: passes make, make check and a full make doc. Reg test comment above

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-26

Originally posted by: k-ohara5...@oco.net

An alternative would be to set 'whiteout' on DyanamicText in contexts with span bars.

Giving dynamics horizontal space in this situation still looks wise to me.

Even after this patch, one can still overrides the X-offset of the DynamicText by hand. The X-offset gives the position of the DynamicText relative to the note-column, so if the overridden X-offset would resolve collisions with the note-column at its natural position, then the note-column will return to that natural position.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-28

Originally posted by: pkx1...@gmail.com

Patch on countdown for December 31 - 06:00 GMT

Labels: -Patch-review Patch-countdown

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-30

Originally posted by: pkx1...@gmail.com

Patch counted down - please push

(NB Keith's comments #22 - in case it prevents the push of this)

Labels: -Patch-countdown Patch-push

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-12-31

Originally posted by: dak@gnu.org

I understand Keith's comment such that this patch does not preclude manual shifts for fixing the positioning if one leans towards the orthodox "human engravers don't anticipate the placement of dynamics when placing the notes" school which I am not convinced of and which precluded a more consistent approach (also affecting cases without span bars) like the one I use to be pushed previously.

Pushed to staging as
commit [r9edf3715c2b2cca09785dcd015724ad3c29cba8a]
Author: David Kastrup <dak@gnu.org>
Date:   Thu Dec 26 16:07:50 2013 +0100

    Issue 621: Dynamics should avoid cross-staff BarLines
    (e.g. GrandStaff, PianoStaff etc)

    Dynamics usually have extra-spacing-width set to an empty interval so
    that their placement does not cause other elements to shift.

    With span bars, however, the resulting overlap is a worse cure than
    the problem. So this switches off the width-hiding setting of
    extra-spacing-width inside of staff groups using span bars by default.
    No extra space is allocated, so dynamics will clear the span bars only
    narrowly, a reasonable compromise.

Labels: -Patch-push Fixed_2_19_0
Status: Fixed

Related

Issues: #621

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc)

Issue Tracker for LilyPond

Searches

Help

#621 Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc)

Related

Discussion

Related

Related

Related

Related

Related

Related