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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
