2017-10-02 23:08 GMT+02:00 Heikki Tauriainen <g034...@welho.com>:
> On Mon, 2017-10-02 at 14:55 +0200, David Kastrup wrote:
>>
>> Looks like a bug in the implementation of
>> commit 327fc82bafec17c249b78b8be19a71ff83b0a32c
>
> No, this looks like an even older bug since the result is the same even
> without this particular change.
>
> From a quick glance at the script's ac:getActions function it looks
> like that the shortening factor which the script will determine for
> each note (by looking at a list of events) could end up being 1:1 if
> the list of events includes any FingeringEvents (which are only one
> among multiple kinds of events with similar behavior), depending on the
> order of the events in the list. This could also explain why the
> output changes when changing the order of the events in the input.
>
> The handling of FingeringEvents appears to been this way since
>
> commit d4c5b03afa8384ee50a7b9536485bc26d14033aa
> Author: Peter Chubb <pe...@chubb.wattle.id.au>
> Date: Mon May 2 13:52:03 2011 +0100
>
> Eliminate faulty barcheck warning in articulate.
>
> --
> Heikki Tauriainen
Yep, so far my own findings are the same.
I'd be interested why it was changed this way. Couldn't find anything
on the tracker or in the archives, though.
Any link would be nice...
Nevertheless some observations/thoughts:
(1)
deleting FingeringEvent from this list makes the initial reported code
work as expected
(2)
obviously StringNumberEvents and StrokeFingerEvent are not even
mentioned, why? What makes them different?
(3)
has it something to do with the known mess of Fingering_engraver and
New_fingering_engraver.
(4)
has it something to do with stopping wrapping all in event-chords?
Because fingering can occur in the 'articulations of a note-event and
in the elements of an event-chord? See:
{ \displayMusic <a-1>-2 }
Cheers,
Harm
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
