Re: Notes on wrong side of stem in triads

[Thomas Morley]

2016-10-23 6:01 GMT+02:00 Paul <address@hidden>:
> On 10/18/2016 12:23 PM, David Kastrup wrote:
>
>> Mark Knoop <address@hidden> writes:
>>>
>>> At 17:05 on 18 Oct 2016, Davide Liessi wrote:
>>>>
>>>> I reproduced the issue with this:
>>>>
>>>> \version "2.19.47"
>>>> \layout { #(layout-set-staff-size 19) }
>>>> { <c'' e'' g''> }
>>>>
>>>> Using #(set-global-staff-size 19) instead works as expected.
>>>> I couldn't find a bug report for this.
>>>> Any ideas?
>>>
>>> Very weird, and certainly a bug. This works as expected also:
>>>
>>> \version "2.19.47"
>>> \layout { #(layout-set-staff-size 19.000000000001) }
>>> { <c'' e'' g''> }
>>
>> Well, _that_ looks like the distance between noteheads is used as a
>> factor for deciding about the arrangement in a manner that is
>> numerically fragile.  Like looking whether their distance is smaller
>> than 1.0 staff line distances.
>
>
> Indeed, the distance between note heads is calculated (via calls to
> Staff_symbol_referencer::get_position for each note head) and that distance
> determines whether a note head is moved to the other side of the stem.  See
> stem.cc line 553 and following where "dy" is the distance between note
> heads:
> http://git.savannah.gnu.org/cgit/lilypond.git/tree/lily/stem.cc#n553
>
> I tried editing line 565 (the comparison involving "dy" that leads to moving
> a note head) and if you remove the 0.1 "safety margin" this fixes the
> problem (while also breaking the placement for some notes that are only a
> second interval apart).  So it does appear to be a mysterious problem of
> numerical fragility.
>
> Some weirdness: if you add \stemUp or \stemDown this fixes the problem, but
> only for chords where the command reverses the default direction of the
> stem.  (!?)
>
> Also, the problem (at size 19 at least) seems to only happen for notes at
> certain staff positions, for example on treble staff, notes at E line, A
> space, C space, and F line (symmetrical pattern around center / zero point
> of staff).
>
> That's as far as I've gotten.  (Won't have time to do any more for at least
> a week.)
>
> -Paul


I managed to identify the first bad commit:

commit cb6024decee0aafd84baafe34115fc1b2d179df6
Author: David Kastrup <address@hidden>
Date:   Thu Nov 13 21:13:12 2014 +0100

    Issue 216: ability to change staff line spacing inside a \layout{} block

    This uses the staff-space setting from the \layout block (if set) for
    determining staff spacing.

    It apparently does not help with horizontal spacing, though.


And indeed, reinstantiating the previous state into a build from
latest master fixes the example.
I've no clue why, though.

Cheers,
  Harm