Re: Auto-beaming infrastructure redo

[Carl Sorensen]

On 7/2/10 5:19 PM, "Trevor Daniels" <address@hidden> wrote:

> 
> 
> Carl Sorensen wrote Friday, July 02, 2010 3:22 PM
> 
> Sounds a promising approach, although some of the details
> remain unclear from your lucid but high-level description.

Yes, to really understand it one needs to see the details.

> 
>> I'm trying to redo auto-beaming so that it matches
>> better with what I read in the literature.  When I
>> get it done, I hope to have it set up so that the
>> default properties do the right thing, and all we
>> have to do is define exceptions.
> 
> By "exceptions" do you mean uncommon time signatures,
> eg 11/8, which could be beamed in a variety of ways?

Partly.  But I also mean that if you want to have beaming other than "split
beams at the ends of beats" and "subdivide beams at the fundamental unit"
you'll need to define a beamException that covers the extra rules you want
to apply.

> 
> Will the present beam ending rules still be needed?

In very few cases.  All of the regular time signatures (simple duple, simple
triple, simple quadruple, compound duple, compound triple, compound
quadruple) will be handled by the defaults.

> 
>> Working in this
>> framework, I think the LilyPond syntax needs to
>> change.  And so I'd like some feedback about
>> (a) names of properties, and
>> (b) the ideas I have for use of properties.
> 
> [snip the description]
> 
>> As I move forward, I think I've settled on the
>> following that I want to have as properties:
>> 
>> 1) subdivideUnit:  a pair (or perhaps moment) that
>> defines the fundamental unit of the meter.
> 
> I agree this would permit a big improvement.  Slight
> preference for pair just to avoid users having to
> invoke make-moment (or whatever it is called) if they
> need to override it.  Presumably by default it is taken
> from the denominator of the time signature?

I agree with the pair.  By default it's (1 . time-signature-denominator).

> 
>> 2) beatLengths: a list that defines the beat lengths
>> in the meter, in terms of the fundamental unit.  If
>> the meter is irregular or complex, beatLengths
>> will be a list of all of the beats in the measure.  I
>> haven't yet settled on what happens in a regular meter.
>> Currently, I still use a list of all the
>> beats in the measure (which is automatically generated
>> when the time signature is changed).  But I could see
>> that for user overrides it might be preferable to only
>> have one entry in beatLengths.
> 
> Stick to using lists.  I think this one format would be
> easier to explain and understand than two formats, one
> for regular and one for irregular meters.
> 
> Alternatively, I like the idea in your reply to Hans of
> beatStructure.  Presumably this would replace beatLengths?
>

Yes, it would.
 
>> 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.

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.

Thanks,

Carl