lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: Issue 638 Autobeaming


From: Carl Sorensen
Subject: Re: PATCH: Issue 638 Autobeaming
Date: Thu, 17 Dec 2009 06:52:10 -0700



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.

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.

I hope this helps you understand.

Thanks,

Carl





reply via email to

[Prev in Thread] Current Thread [Next in Thread]