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

[Mark Polesky]

Wow. Thanks for all the replies. I'll answer one at a time, all
below.

David Kastrup wrote:
> I don't think so.  The purpose of staff changes is to avoid help
> lines. In particular where they would require systems to be
> paced further apart.  For this, the average is irrelevant, only
> the total range (top and bottom note lines) is of interest.  A
> staff change is a drastic measure: one will not typically do it
> unless more than two help lines would otherwise occur.  So it is
> really a matter of the total vertical extent (after considering
> the signature, so an f flat counts as higher as an e sharp,
> never mind that its pitch is lower) and not the pitch average.

First, I'm sorry that I was not more accurate. I should have said
average "staff-position", because the actual sounding pitch (as
well as any accidentals anywhere) is totally irrelevant here.

Middle C can be thought of "zero". D is 1, E is 2, B is -1, A is
-2. Accidentals are completely ignored. So D-double-sharp is 1 and
E-double-flat is 2. So the average staff-position between C and E
is 1, and the average staff-position between B and E is 0.5.
However, non-integer values crash the function, so they need to be
rounded. The crucial specification is that if the staff-position
average is between -1 and 1, but is *not* zero, than it cannot be
rounded to zero. So the result of the averaging will be 1 for
<b e> and -1 for <a d>.

____________________


Mark Knoop wrote:
> I presume by "help lines" you mean ledger lines?
>
> But you're correct that neither the average pitch or even the
> average pitch of the outer notes of the chord is enough.
>
> Consider the following:
>
> <d' f'>8 <b, f'> <d' f'> <b, f'>
>
> Clearly this would be best set in the bass clef, however the
> average pitches (e', gis) would (probably) result in it swapping
> between the two staves.
>
> So it's actually the extremity of the chord in the direction of
> potential staff change that is of primary importance.

That's interesting. But that's not quite it. You can see why if
you re-do your example backwards:

<b, f'>8 <d' f'> <b, f'> <d' f'>

The first chord clearly goes in the bass staff. And I agree, the
second chord should also go in the bass staff. But if we only look
at "the extremity of the chord in the direction of potential staff
change", we'll end up putting the second chord in the treble staff
anyway.

What do you think about this:

If chord1 is in the lower staff, and chord2 would normally go in
the upper staff, and the highest note of chord2 is higher than the
highest note of chord1, then put chord2 in the upper staff,
otherwise keep chord2 in the lower staff.

If chord1 is in the upper staff, and chord2 would normally go in
the lower staff, and the lowest note of chord2 is lower than the
lowest note of chord1, then put chord2 in the lower staff,
otherwise keep chord2 in the upper staff.

Is that it? Or can this still be improved? Remember, we need to be
as specific as possible and devise an algorithm that works well in
all the cases that we can imagine (within reason).

____________________


Werner LEMBERG wrote:
> >> Anyway, I think that it would make a lot more sense if the
> >> staff were determined by the "average" pitch of the chord.
> >
> > I don't think so.  The purpose of staff changes is to avoid
> > help lines.
>
> Perhaps it makes sense to provide different `modes', depending
> on the purpose.

That's another interesting idea. I'll try to keep that in mind,
but I need to decide on a good general algorithm first.

____________________


Trevor Daniels <address@hidden> wrote:
> 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 ;)

Yes, I imagine that algorithmically-generated LilyPond code
is not likely to appreciate the subtlety of note-entryorder.

> 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 :)

Would the algorithm I proposed above in response to Mark Knoop
suffice?

> 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.

That's an excellent idea, although I don't know how easy that's
going to be to implement. But once I'm at a place where I'm
ready to experiment with that, I probably will. As with Werner's
idea, I'll try to keep it in mind.

____________________


"address@hidden" wrote:
> What would make the most sense is to consider the range of the
> intended instrument.  music for a mid-range instrument (eg
> classical guitar) is conventionally presented on the same
> suboctave G clef a tenor vocalist uses.
>
> Some music for low brass and winds uses c-3, c-4, and f-4 clefs.
> Hopefully these automatic clef changes are an optional feature,
> many players find any clef change annoying.

At the moment, we're talking about automatic staff changes, not
clef changes. And yes, this behavior is very much an optional
feature. The user must explicitly enter the command \autochange.

> > 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.
>
> What of music contrasting the extremitys of a pianos keyboard,
> is it always going to be coded as two strains of polyphony?
> (left hand vs right).  If coded for one hand, no changes at all
> are apropriate there, just alternation as to which half of the
> combined staff is employed (allowing some few ledger lines).

Actually, that's my exact reason for tweaking this. I'm actually
not so interested in auto-staff-changes, but I need to understand
it so I can design an auto-clef-change function. And in the course
of studying the staff-change stuff, I'm seeing opportunities for
improvement that I don't want to ignore.

> Look to the earliest publications of Ottaviano Petrucci (Canti
> C, Canti B, Odhecaton), available in facsimile at the best music
> libraries (and direct from Broude Brothers if you care to
> purchase) for examples of how rare clef changes were even when
> movable C clefs were the norm.  Initial clef should be chosen
> based on overall range, proposed changes should be evaluated in
> the light of ledger line use.  Knowledge of the intended
> instrument and modern/classical scribal conventions could expand
> the range of clef choices.

I don't think that's an issue here.


> Such fun devising heuristics.

Yep.

____________________


Thanks again, everyone!
- Mark