Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.

[Trevor Daniels]

Mark Polesky wrote Wednesday, July 22, 2009 8:32 AM

> In NR 2.2.1 Changing staff automatically, it says this:
>
> Chords will not be split across the staves; they will be assigned
> to a staff based on the first note named in the chord construct.
>
> http://kainhofer.com/~lilypond/Documentation/user/lilypond/Common-notation-for-keyboards.html#Changing-staff-automatically
>
> Actually, this is not true; they are assigned to a staff based on
> the *last* note named in the chord construct. The reason is that
> in scm/autochange.scm, the NOTES variable referenced on line 17
> ultimately comes from a *reversed* context-list (see line 38).

Clearly this needs to be corrected.

> Anyway, I think that it would make a lot more sense if the staff
> were determined by the "average" pitch of the chord. And, I think
> I've solved this in the attached patch.
>
> I've also attached 2 png's to demonstrate the difference: the
> first one (current.png) was compiled with the current
> autochange.scm and the second one (revised.png) was compiled with
> my revised patch. You can look at the test file below to see how
> it is set up.
>
>
> Would anyone like to comment?
> Are there any objections to me applying it?

Yes and yes.

I think this would not result in an improvement
in the general case.  In a passage in which the
average fluctuated rapidly above and below middle C
too many staff switches would be generated.  The
present scheme does not do this as (in a chord)
you can choose to have the based on the higher
or lower note depending on the order in which they
appear.  This probably offends your semantic
sensibility though ;)

Actually a scheme based the switch on the
position of either extreme of the chord would
be an improvement, which extreme being specified,
and would restore the correct semantics :)

Also being able to specify a lower limit on the
number of notes/chords permitted on the staff
to be switched to, to prevent short runs, would
also be useful.

> - Mark

Trevor