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 09:21:29 -0700



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

> "Trevor Daniels" <address@hidden> writes:
> 
>> Carl,
>> 
>> A question.  Does your code require autobeaming
>> rules to be defined for beams of every possible
>> duration?  I ask because the following example beams
>> inconsistently, and I'm not sure if this is due to your
>> code or differences in the autobeaming rules for 4/4 and
>> 2/2 time signatures.  With a32 instead of a64 a64 the
>> beaming is fine.
>> 
>> \relative c'' {
>>  a8 a a a32 a a a a8 a a a64 a a32 a a |
>>  a8 a a32 a a16 a8  a8 a16 a32 a a8 a|
>>  \time 2/2
>>  a8 a a a32 a a a a8 a a a64 a a32 a a |
>>  a8 a a32 a a16 a8  a8 a16 a32 a a8 a|
>> }
> 
> 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)))

Under your proposal, the second is equivalent to the first as it is
currently implemented.

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.

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.

There is one other implicit rule  -- that we break on beats if there's no
other rule.  I think that with the fairly recent change to the default rule,
perhaps there's no need to have that implicit rule any more.

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.  Then,
if things didn't work, you wouldn't have to wonder why; you'd only need to
go look at your beaming rule.

Thanks,

Carl





reply via email to

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