[Top][All Lists]
[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
- PATCH: Issue 638 Autobeaming, Carl Sorensen, 2009/12/16
- Re: PATCH: Issue 638 Autobeaming, Andrew Hawryluk, 2009/12/16
- Re: PATCH: Issue 638 Autobeaming, Frédéric Bron, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, Carl Sorensen, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, David Kastrup, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, Carl Sorensen, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming,
Carl Sorensen <=
- Re: PATCH: Issue 638 Autobeaming, David Kastrup, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, Carl Sorensen, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, David Kastrup, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, Carl Sorensen, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, Carl Sorensen, 2009/12/17
- Re: PATCH: Issue 638 Autobeaming, Trevor Daniels, 2009/12/18
- Re: PATCH: Issue 638 Autobeaming, Trevor Daniels, 2009/12/18
- Re: PATCH: Issue 638 Autobeaming, David Kastrup, 2009/12/18
- Re: PATCH: Issue 638 Autobeaming, Carl Sorensen, 2009/12/18
- Re: PATCH: Issue 638 Autobeaming, David Kastrup, 2009/12/18