Re: Auto-beaming infrastructure redo

[Trevor Daniels]

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.

> 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?

Will the present beam ending rules still be needed?

> 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?

> 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?

> 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.

> Carl

Trevor

_______________________________________________
lilypond-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/lilypond-devel