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: Fri, 18 Dec 2009 10:32:57 -0700



On 12/18/09 10:13 AM, "David Kastrup" <address@hidden> wrote:

> Carl Sorensen <address@hidden> writes:
> 
>> On 12/18/09 3:58 AM, "David Kastrup" <address@hidden> wrote:
>> 
>>> I think that if we establish the rule "a broken beam decision is
>>> never reconsidered" we can abolish the '* rule for beaming patterns
>>> and instead let a non-specified minimal duration always be broken
>>> according to the time intervals of its next-larger cousin.
>>> 
>>> That would simplify the default patterns, not cause problems when new
>>> lengths get supported, and make it harder for users to specify
>>> patterns manually with accidentally undefined behavior.
>>> 
>> 
>> So which do you think does a better job of being clear as a (4 . 4)
>> beaming rule:
>> 
>> (( * . (1 1 1 1) ((1 . 8) , (4 4)))
>> 
>> or
>> 
>> (((1 . 8) , (4 4)) ((1 . 16) , (4 4 4 4)))
> 
> I'd say the latter, since the former requires
> a) an additional special symbol
> b) with its additional special timing unit that actually can't be
>    guessed without looking at the time signature, too.
> 
>> Under your proposal, the second is equivalent to the first as it is
>> currently implemented.
> 
> Yes.
> 
>> I can see some benefits to assuming that a beams with shorter notes
>> will not be broken into larger groups beams with longer notes unless
>> there is a specific rule requiring it.
> 
> Uh, your algorithm depends on this, right?

No.  The algorithm does not go through the entire bar in order of decreasing
note values.  It looks at things on a time basis, so if a 1/64 note appears
in the beam, the 1/64 beaming rules apply.  The algorithm works just fine
with making 1/64 note beams break at longer places than 1/32 note beams.  In
fact, the example you created shows that; the whole measure is beamed
together.

> 
>> I am less happy about having implicit rules being defined without any
>> mention of it.  In the second example, there are implicit rules for
>> 1/32, 1/64, and 1/128 beaming, but I can't see that from reading.  In
>> the first example, all beams are explicitly covered.
> 
> But in the case of 2/2 timing, the current setting is
> ((* . (1 1)) ((1 . 32) . (8 8 8 8)))
> 
> If you don't want to revisit every rule whenever a new note duration is
> added, * may only cover the shortest duration (under your algorithm's
> assumption which I find reasonable).  So this would need to be
> ((* . (0.5 0.5)) ((1 . 8) . (4 4)) ((1 . 16) . (8 8 8 8)))

This rule is not self-consistent.   There's only  half a measure of notes in
the default rule, and two measures of notes in the (1 . 16) rule.

I don't revisit every rule whenever a new note duration is added.  The rule
that applies is the rule for the shortest duration in the beam.
 
> Which suffers from the slight problem that 0.5 (half a beat) is not even
> an option in the * format.

Yes, it's a slight problem.  We can fix the problem by making rules have
break moments, instead of groupings, which is probably more clear anyway:

((* . ((1 . 4) (1 . 2 ) (3 . 4) (1 . 1)))
 ((1 . 8) . ((1 . 2) (1 . 1)))
 ((1 . 16) . ((1 . 2) (1 . 1))))

which is probably closer to what was intended by the current rule.

> 
>> I think I would be in favor of eliminating *all* implicit rules, and
>> having autobeams break only when they are asked for by some explicit
>> rule.
> 
> And on the end of bar.

Yes, I think so.  Although when I write the default rules, I will put in an
explicit rule for ending at the end of the bar.

Thanks for your feedback,

Carl





reply via email to

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