Alexander Kobel, Kieren MacMillan and others have requested the ability to centre dynamics accurately between the piano staves. Alexander has offered a 50 Euro bounty and Kieren has offered to supplement this.

This "solution" was suggested by Kieren:

"After thinking about it a bit, it seems to me that the current (wicked awesome, BTW) skyline coding could come to the rescue here... =)

IMO, the ultimate algorithm for a piano-with-centered-dynamics situation might be as follows:

1. At any given point requiring a dynamic/hairpin, the grob-box containing the dynamic/hairpin is inserted between the skylines of the two surrounding Staff contexts.

2a. If this insertion can be done without the dynamic/hairpin box touching either skyline, the two Staff contexts remain unaffected. 2b. If the dynamic/hairpin grob-box touches either skyline, the lower Staff context is pushed down until the grob-box no longer (or just barely) touches the skylines. [In other words, this context would be "super-skylined" or "flatline-able", with a minimum height of 0 where a Staff context has a minimum height of 4.]

3a. The dynamic/hairpin grob-box #'padding would be user-settable. 3b. There would also be a setting (default = ##f) which would force all dynamic grob-boxes within a single system to be aligned on the same vertical axis."

I am making an explicit offer of US$100 on this fix.

I have a hard time imagining what "centre dynamics accurately between the piano staves" is supposed to mean. Presumably the center is determined between the staves itself without any look at skylines or other material. And presumably the center of the dynamics box is determined as a font- (but not content-) dependent fixed height above the baseline, so that variations in descenders and ascenders don't affect the center. Even though they do affect the skyline and may, for that reason, push both staves away by equal amounts.

Does that sound about correct?

Attached is a hand-engraved example of centred dynamics from a piano score [1]. The individual dynamic marks are centred between the skylines by shifting the baseline as needed. In contrast, the current behaviour [2] uses a Dynamic context that aligns every dynamic to the same baseline, often forcing the music to take up much more space than necessary.

In principle, the desired output could be achieved by using the adjacent system skylines to vertically position the grobs within a Dynamic context and then the existing vertical layout can still be used to position the context between the staves (afinity = #CENTER). The vertical positioning would be taken from the average of the two skyline offsets, e.g. if the right-hand music takes up 3 spaces below its staff, and the left-hand music takes up one space above its staff, the dynamic at that position should be shifted down one space from its default position. ((-3) + (+1)) / 2 = -1 The tricky part is that the upper and lower staves must be laid out before the dyanamics, and the Dynamics engraver must have access to those skylines.

At least, that's how I understand this issue.

-Andrew

[1] Beethoven, Sonata 13, Edition Peters. http://imslp.org/wiki/Special:ImagefromIndex/30364 This edition is also an excellent example of dynamics that intentionally impinge on the staff lines to allow tighter page layout.

[2] e.g. http://lilypond.org/doc/v2.14/Documentation/learning/piano-templates

The example in the last comment is extreme IMHO, but it points into the right direction. Let me formulate a possible algorithm slightly differently:

1. In the normal case, the piano staves are at a fixed distance, and dynamics are vertically centered in between.

2. If necessary, the distance between the staves is increased so that the skylines don't touch.

3. For the computation in rule 2, vertical positions of dynamics are adjusted so that there aren't vertical collisions.

4. All dynamics which haven't been vertically shifted so far are now centered between the staves (not between the skylines).

5. If the difference between the vertical position of a dynamic grob and the vertical center between the skyline at the current horizontal position is large, shift the dynamic grob by a user-definable fraction of this vertical difference.

This is confusing. Let's use pictures. Comment 1 (part 2a) says to spread the staves if centered dynamics hit either skyline, which I interpret as line 1 in the attached image. The final pp would hit notes on the upper staff (but not the lower) if it were centered between staves that are any closer.

Comment 3 talks about moving dynamics when needed, and centering them when there is enough room, line 2 in the attached image. (I added a nonsense p in blue because the other dynamic locations were forced.)

Your second system looks almost perfect, Keith! And the vertical position of the blue p looks good also. The only remaining issue (not covered with the second system) is the unforced vertical position of a dynamic, where the vertical center between the staves and the vertical center between the skylines differ greatly.

Let's for a moment assume that the first system is the perfect solution. Then I maintain that the vertically unforced position of the (black) p is not optimal: The difference between the vertical center of the skylines and the vertical center of the staves is quite large, and a user-defined correction factor should be applied to shift it up IMHO.

+1 for Keith's work second result. I guess I have to rephrase my demand to "sensibly centered dynamics". To yield this, I wonder whether it already suffices just /not/ to keep a common baseline for the Dynamics. Instead, adjust each DynamicScript independently of the others. (No clue how hard this is to do, though. From my naive POV, it should be equivalent to instantiate a new Dynamics context for each DynamicScript, but in fact it's not as simple as that...)

Also +1 for Werner's idea of a correction factor between "staff" and "skyline" spacing.

Don't forget, though: we need the syntactic option to denote groups of dynamics to be aligned together (e.g., several hairpins close together on the same baseline).

So it seems the desire is to move individual dynamics (or groups linked as per issue 1362). When the music is tight the dynamics are forced midway between the skylines of the staves; when spacing gets loose they go midway between the staves.

To show the transition between loose- and tight-limits, I made a picture with tight spacing in the middle, and one extra staff-space between staves at top and bottom. The top system has dynamics return to the center line between staves as quickly as possible; the bottom system has dynamics follow the mid-line between skylines. Anything between these two would look pretty good to me.

The examples just use tweaks. Having Lilypond do it automatically takes some careful work, because Lilypond places everything relative to its home Staff or Lyrics context before working on the relative placement of Staves.

Thanks for the example! I prefer the bottom staff to the top one, except that it would be desirable that the dynamics in the second and third bar stay slightly more aligned vertically. No idea whether this is possible.

Could you show us how it looks if you add two or three extra staff-space between the staves? Maybe I have to withdraw issue 5 of my proposed algorithm in favour of centering between the skylines...

Could you show us how it looks if...

Oops; I meant to attach the .ly file.

This is a very helpful example, Keith. Either version 2 or 3 looks right to me, with 3 being preferable if space permits. Skyline-centred dynamics seem to be the norm in the scores I have perused this week, and they also have semantic value: keyboardists must sometimes distinguish between centred dynamics that apply to both hands or dynamics that only apply to one hand (or even to one voice within a hand). Ideally, LilyPond would apply the centred dynamics to both staves, but that probably belongs in another discussion. Thanks again!

The comment in #11 is a good one, I haven't thought of this. So centering between the skylines is more preferable, perhaps combined with a certain unwillingness of the dynamics to move vertically too much so that they are slightly more aligned horizontally.

Dear all,

I withdraw my promise for a 50 EUR-bounty on a solution of this issue.

This is not because I don't feel it's worth to deal with, or that it suddenly became very easy - quite the contrary. But since more than a year, I rarely used LilyPond - simply because I almost never need self-made sheet music anymore. I want to make sure that nobody is surprised if at some point in the unforeseeable future a dedicated and hard-working contributor solves the issue and claims his well-deserved money for a nice dinner, and I completely forgot about the issue in the meantime. Or, worse, I cannot even promise I will care by then - we're human after all. Plus it turned out that we don't have a clear specification how the optimal output looks like, and I want to save everybody the hassle of discussions and follow-up negotiations about further fixes whether (incremental?) improvements already satisfy the goals of the "request".

The money is not lost for LilyPond, though: it went to two contributors who are well known and very active these days, and who are fixing an incredible number of small and big issues in so many places I cannot count them. Thanks to all of you!

Alexander

Greetings everybody, In exchange for Alexander withdrawal, I’m throwing in a €150 bounty of my own on this issue (in addition to whatever Kieren’s up to :-)

Just as a side note, do keep in mind that not all dynamics are centered in a piano score, there may be places where the author intends to differenciate one hand over the other (see Ligeti’s Etudes for example). What I usually do (with an ugly hack) is that I keep dynamics entered with an explicit direction (e.g. c^\f ) attached to the staff, whereas standard dynamics are sent to a Dynamics context living between the staves (although not correctly centered, as this issue demonstrates). It’s the most flexible and useful solution I could come up with, but maybe there are better ones out there.

I'm still in for US$50. As for the "hack" Valentin mentioned… I also do the same. But it would be great to make it Do The Right Thing™. Maybe there could be a setting which temporarily "un-sprung" a dynamic text, so that it was fixed to the bottom of the staff above or the top of the staff below, regardless of how the rest of the dynamics slid around or centered themselves? (Obviously, any dynamics explicitly above the upper staff or below the lower staff would have to be added in that music directly, rather than attached to this centered Dynamics context.)