Currently beam thickness is defined in terms of staffspace only. That gives unsatisfactory results.

Staffline thickness (measured relative to staff height) changes with staff size (it gets relatively thicker with smaller staff sizes), while beam thickness does not change (because it's defined in staffspaces). This leads to poor results: for staff-size 20 beamThickness/stafflineThickness ratio is 4.8, while for staff-size 10 it's only 2.9 - beams in small sizes appear thin.

In other words, "optical sizing" (described here http://lilypond.org/doc/v2.17/Documentation/essay/engraving-details#optical-sizing) doesn't work for beam thickness.

let beam thickness depend on line thickness (fix 3173)

One of LilyPond's design principles is "optical sizing" (described in Essay, section Engraving details), which means that as the font-size gets smaller, all elements get relatively thicker.

Before now beam-thickness was defined as a fraction of staffSpace, which meant no optical sizing (the thickness of the beam stayed constant relative to the height of the staff). This patch changes beam-thickness property to be a pair of numbers (a . b). The actual thickness is calculated according to the formula a * lineThickness + b * staffSpace (similarly to ledger line thickness).

http://codereview.appspot.com/7312091

The result of the patch above is attached (in case of staff-size 20 the output is identical).

Feedback please?

Fails make check..

cryptic for me but the logs I can find say

--snip-- /tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/lily-library.scm:54 4:3: In procedure list-index in expression (list-index (lambda # #)): /tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/lily-library.scm:54 4:3: Wrong number of arguments to # --snip--

That line is in list-element-index. That function has apparently broken by me in October. Its only use is when a multi-job run aborts with an error somewhere. I'll push a fix for that soonish (astonishing that this has not been seen before), but if you have the logs still around, the real error causing a non-zero exit state (including segfaults, so if we are unlucky, there will be nothing to be seen) will likely have occured before that.

git grep beam-thickness shows several occurences in regression tests as well as in documentation. Can't this be made into a callback instead, something like (define ((line-staff-proportional line-factor staff-factor) grob) ...) and then used as (beam-thickness . ,(line-staff-proportional 0.4 0.1)) or similar? That way it remains backwards-compatible, mnemonic, and line-staff-proportional (or whatever else it may be called) is useful in other situations as well.

@David (comment #4): did you fix that already?

@David (comment #5): that's an interesting idea. I think i see something even better that could be done here, but that's a separate issue - i'll write about it later.

Re comment#4:

git log --grep list-element-index spews out commit 7d886e6650ebc275c82a6770827380e883706c50 Author: David Kastrup Date: Thu Feb 14 16:12:22 2013 +0100

Fix typo in list-element-index, simplify count-list

Indeed, i should've checked this myself. Thanks for fixing!