#3653 Beam ends not matched to StaffSymbol thickness

[Anonymous]

https://codereview.appspot.com/339210043/

Originally created by: ColinPKC...@gmail.com

From Peter van Kranenburg, verified by Harm:

\version "2.17.95"

\new Staff \with { \override StaffSymbol #'thickness = #4 }
\relative c'' { g16 a b c }

The beam does not overlap the stems of the notes entirely, which does not look very nice (see attached png). It should start at the left of the first stem and end at the right of the last stem rather than in the center of both.

[Google Importer]

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

Followup by Peter on lilypond-user:
I found a solution myself:

\version "2.16.2"

\score {
\new Staff \with { \override StaffSymbol #'thickness = #2.5 }
{ \relative c'' { \override Stem #'beamlet-default-length = #'(0.16 . 0.18) \override Beam #'clip-edges = ##f g16 a bes c } }
}

It might not be a proper use of these parameters, but it works for me.

[Google Importer]

Originally posted by: janek.li...@gmail.com

\markup {
  \scale #'(3 . 3)
  \score {
    <<
      % normal staff - everything is okay
      \new Staff
      \relative f' {
        a8[ a]
      }

      % if we decrease or increase stem thickness, beam adapts correctly
      \new Staff
      \relative f' {
        \override Stem #'thickness = #(magstep -12)
        a8[ a]
        \override Stem #'thickness = #(magstep 12)
        a8[ a]
      }

      % but if we change staff thickness, which influences stem thickness,
      % beams are wrong (if you zoom at the first beam, you'll see that
      % it's too long; the second one is obviously too short).
      \new Staff
      \relative f' {
        \override Staff.StaffSymbol #'thickness = #(magstep -12)
        a8[ a]
        \stopStaff
        \override Staff.StaffSymbol #'thickness = #(magstep 12)
        \startStaff
        a8[ a]
      }
    >>
    \layout {
      indent = 0
    }
  }
}

[Google Importer]

Originally posted by: Carl.D.S...@gmail.com

If you look carefully at what's going on, you 'll see that when the staff thickness is increased, the beam is shifted upwards, but the stem is not lengthened to match.

The current design in the default is that the beam ends on the midpoint of the stem, and the stem ends at the top of the beam.

With the staff thickness increased, the stem no longer ends at the top of the beam.  Hence the mismatch.

[Google Importer]

Originally posted by: janek.li...@gmail.com

That's not true.  The stem *always* ends in the middle of the beam (it must do it or the slanted beams would look bad).  See attached.

In the last case the beam ends up higher indeed - but the stems are lenghtened as well so that they end in the middle of the beam.  I suppose the beam goes higher to ensure that the distance between it and the top staffline is greater than some value.

\markup {
  \scale #'(5 . 5)
  \score {
      % normal staff - everything is okay
      \new Staff \relative f' {
        \override Stem #'color = #green
        \override Stem #'layer = #10
        a8[ a] f[ b]
      }
    \layout {
      indent = 0
    }
  }
}

[Thomas Morley]

The workaround above does not work if StaffSymbol.thickness is smaller than default.

\new Staff \with { \override StaffSymbol #'thickness = #0.25 }
\relative c'' { 
    \override Stem #'beamlet-default-length = #'(0.16 . 0.18) 
    \override Beam #'clip-edges = ##f 
    g16 a32 bes c16 d 
} 

Looks even better without the overrides.
Any further hint?

[Torsten Hämmerle]

After more than a year's absence from the web, it's time to join in again...

Stem width and Beam positioning
All of LilyPond's calculations are basically correct - there's only one flaw in the C++ coding:

file: beam.cc -- function: Beam::calc_beam_segments
Instead of using the actual stave line thickness, the C++ coding accidentally reads the general layout line thickness, so that changing the stave line thickness has no effect on the beam at all:

:::c++
Real lt = me->layout ()->get_dimension (ly_symbol2scm ("line-thickness"));

Solution:
I's basically a one-line change in beam.cc: variable lt should be set using Staff_symbol_referencer::line_thickness.

I've set up LilyDev 4.1 and the proposed solution seems to be working (I'm not sure about the attachment upload, though)...

[Thomas Morley]

Hi Torsten,

welcome back!!
I hope it's all ok with you, we all have been worried.

Ontopic:
Your analysis sounds reasonable.
I'm eager to see your patch
I recently had to heavily manipulate beam-segments from scheme. It's a hassle ...

[Torsten Hämmerle]

I've uploaded the patch to rietfeld. Automatic issue tracker update didn't work due to missing project authorization, so I'm posting it manually for the time being.

https://codereview.appspot.com/339210043/

All the best
Torsten

@Harm: Sorry, it took quite a while because I was fooled by the current regression test issue with random rest dot placements in rest-dot-position.ly ;)

[Thomas Morley]

Ask on devel for authorization with your sourceforge user-name. Meanwhile I edited the tags accordingly.

[Torsten Hämmerle]

Thanks, Harm, I've just sent a mail to devel (beware of auto-correct!).

[Anonymous]

Passes make, make check and a full make doc.

[Anonymous]

Patch on countdown for Jan 19th.

[Anonymous]

Patch counted down - please push (if you don't have commit access, can you make a git-formatted patch agains current 'master' and attach to the incident? I or someone can then push it for you).

[Torsten Hämmerle]

Hi James,
Please find attached a patch-file against current master as requested, since I do not have push access.
Thx Torsten

[Anonymous]

author  Torsten Hämmerle <torsten.haemmerle@web.de> 
Fri, 19 Jan 2018 21:41:48 +0000 (22:41 +0100)
committer   James Lowe <pkx166h@gmail.com>  
Sat, 20 Jan 2018 12:12:06 +0000 (12:12 +0000)
commit  b0c416d0eac15b7022c9ca27e6cfee97f2ba786a

Many thanks Torsten.

I expanded the commit message based on what you wrote in this ticket for additional information.

[Torsten Hämmerle]

Thank you, James, I really appreciate your help and support.

[Federico Bruni]

I still see a mismatch when I try the snippet in the initial report and compile it with version 2.19.81.

There's any simple example which shows what changed before and after this patch?