Re: Fix temporary polyphony "for good" (was 'Re: Ties in complex polyphony')

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

>> So what?  That's more of a reason to get rid of the idiosyncrasies
>> rather than providing incomplete commands with strange semantics
>> that people then start relying on.
>
> Which is exactly why I posted my question in the first place: trying
> to promote the elimination of [one of] Lilypond's idiosyncracies.
>
> In any case, there are too many idiosyncracies for the small
> development team to take care of "immediately". Hence we are forced to
> use (and "start relying on") many, many, many, many — is my point
> clear yet? — many, many "incomplete commands with strange semantics"
> in order to get our work done.
>
> At least some of us use Lilypond very heavily on a daily basis. For
> example, this week alone I: finished composing and engraving a
> 12-minute song cycle for piano, cello, and voice; updated scores of
> three different (all relatively complex) multi-act music dramas; and
> prepared score files for five movements which will include very large
> forces (double orchestra plus three smaller ensembles plus two choirs)
> to be filled in with new compositions/arrangements over the next few
> weeks.
>
> Waiting around for proper implementations of things like temporary
> polyphony is not a real option if I want to get my work done in a
> timely fashion.

Sure.  But the simple workarounds are easy to do _and_ understand.  If
you feel that the respective approaches are underdocumented, you may be
right.

But the solution for not understanding how something works is
documentation, not wrapping something into a function for which one does
not understand how it will work in practice.

Music functions provided by LilyPond are documented blackboxes.  They
should do a given job well, and reasonably completely and
comprehensively.  They should solve a _task_, rather than being a
shortcut for a somewhat useful piece of code related to a task.

What you propose as "\split" is too hackish and limited and arbitrary to
turn into a core music function.  That does not mean that something like
that should possibly be explained more thoroughly in the documentation.
But it does not reach the level of a turnkey solution.

-- 
David Kastrup