Re: PATCH: Issue 638 Autobeaming

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 12/17/09 1:25 AM, "David Kastrup" <address@hidden> wrote:
>
>> Carl Sorensen <address@hidden> writes:
>> 
>>> On 12/16/09 10:23 PM, "Frédéric Bron" <address@hidden> wrote:
>>> 
>> 
>> Deep breath.
>> 
>> So it would appear that no terminal/irreversible decision based on the
>> minimum duration has been done yet at this point of time.
>> 
>> If that is the case, why not postpone all of the minimum-duration
>> dependent accounting to the time where it is actually _needed_?
>> 
>> There does not seem to be much sense in making some temporary
>> calculation based on possibly wrong assumptions when one can safely do
>> it at a later point of time anyway.
>
> Further thought on the issue has led me to this point that will
> hopefully clarify things.

I am getting clearer on that, yes.

> After a note has been added to a beam, we ask the question "Should we
> end the beam now?"  An answer that says we *should* end the beam is
> final and irrevocable.  This is the code that has been implemented for
> a long time in LilyPond.
>
> The problem we have had in the past is that a decision to continue the
> beam is *not* final.  If shorter notes are added to the beam, the beam
> may need to be divided.  The classic example is beaming in 4/4 time.
> If only eighth notes are in the beam, the beam should cover the first
> two (or the last two) beats of the measure, i.e. be broken only
> between beats 2 and 3.  However, if a sixteenth note is added to the
> beam, it should be broken between beats 1 and 2, 2 and 3, and 3 and 4.
>
> Given that breaking decisions are final, it seems appropriate to me to
> keep typesetting a beam anytime a break condition is found.
>
> And given that continuation decisions are subject to review if a shorter
> duration is added to the beam, it seems appropriate to me to review the
> continuation decisions whenever the shortest duration changes.

The problem I keep having is the following: if you put it like that, no
code _can_ rely on the consequences of a continuation decision.  Because
that decision may be revisited.  If revisiting the decision is an
option, then maybe postponing the decision is a better option.

Because then we can make all the decisions in one go.  If
reverting/revising decisions happens in a different code path than the
code path making the initial decision, the code becomes harder to
maintain, since any changes at one decision point have to be reconciled
with the revert/revise code path as well.

Also a programmer might expect that the choice that the code makes is
persistent, and misses the other half of the story written at a
different point of the code.

Let me take an example: the following code is by default set
inconsistently (I have not yet tried your patch on it).

{
  \time 2/2
  \repeat unfold 21 { c'64 c'32 } c'64
}

You'll see that the first quarter is beamed separately.  The last
quarter isn't, even though the measure is symmetrical.  Second and third
quarter could not be beamed separately because one 32th spans across
them.  But does it make sense to let this affect the fourth quarter?

The more the beaming decisions get distributed across different points
of time and code paths, the harder it gets to track down what happens
where.

What behavior can a composer expect when he changes the beaming patterns
in mid-measure?  With the revised code, it appears to me that the
initial choice of beaming might happen with one set of patterns, and the
revision with a different one.  Is the code robust enough to cope with
that situation?

So I'm paranoid, and not smart enough to see through complex code.
Which is why I prefer simple code.  I don't say that simpler code is
possible here.  I just say I wish it were...

-- 
David Kastrup