Re: Auto-beaming infrastructure redo

[Carl Sorensen]

On 7/3/10 3:11 AM, "Trevor Daniels" <address@hidden> wrote:

> 
> 
> Carl Sorensen wrote Saturday, July 03, 2010 1:06 AM
> 
> 
>> On 7/2/10 5:19 PM, "Trevor Daniels" <address@hidden> wrote:
>> 
>>> Carl Sorensen wrote Friday, July 02, 2010 3:22 PM
>>> 
>>>> I've got mixed feelings about the following property:
>>>> 3) beatCombinations: an alist with a key of beam type,
>>>> and a value of the beats that can be combined for that
>>>> beam type.  This is currently only used for 3/4 and 4/4
>>>> time, and it doesn't really capture the special rules used
>>>> for 3/4 and 4/4 time (although it comes close).  I can't
>>>> decide whether to create this general property and use it
>>>> to define rules for 3/4 and 4/4 time, or whether I should
>>>> just go ahead and hard-code the special rules for 3/4 and
>>>> 4/4 time (so I could get them perfectly).
>>> 
>>> My feeling is to hard-code these.  I've tried to think of
>>> generic ways of parameterising them and failed.  The rule that
>>> "a beat in simple time that is divided into more than two parts
>>> cannot be connected to another beat" is the tricky one.  Nor
>>> can I think of any other circumstance where such a rule might
>>> be needed.
>> 
>> Actually, that rule is pretty easy.  I just make it apply to only
>> 1/8 note
>> beams.  It doesn't catch everything, but it mostly works.
> 
> Of course!  I was trying to find ways of counting stems!
> 
>> The hardest one is "don't split beat 2 of 3/4 into two parts".
>> I'm still
>> not sure exactly how to implement that.
> 
> As we discussed earlier, this rhythm, f4 r8 f f f, could be
> handled by implementing a 'start' rule as well as an 'end' rule,
> to be sure beams could be started only on beats, couldn't it?

Yes, I've added start rules that solve that problem.  I don't only start on
beats, but I avoid starting on the last note of a beat.  After all, I think
we'd want the 16th notes in r8 f16 f f8 f f4 beamed together.

The harder problem is

f8 f f r f f

which will beam the first 3 notes together under the current rules.

> 
> The other tricky combinations like f8 f~f f f f and d'4. c8 b8. a16
> are not specific to 3/4.  The former applies to tied notes over
> beats in any time signature, I think; it means beams should be
> broken if there is a tie carrying over a beat, presumably to
> ensure the tie is seen more clearly.  The latter of these two
> is really tricky: the beam should be broken at the beat if the
> rhythms in the two parts are similar but not identical.  Some
> of the commonly occuring patterns could be trapped by beam
> ending rules maybe, but implementing it in full generality?
> Perhaps we let that one be resolved by manual beaming!

I'm willing to let most of the hard rules be resolved by manual beaming.

A revised way of calculating beaming in the future that includes beat counts
and stem counts is possible (although I haven't architected it yet).  Right
now, I just want to make sure that the necessary properties are in place, so
they don't have to be changed again.

I think that subdivideUnit (or fundamentalUnit) and beatStructure are a good
set.

Thanks,

Carl