[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auto-beaming infrastructure redo
From: |
Trevor Daniels |
Subject: |
Re: Auto-beaming infrastructure redo |
Date: |
Sat, 3 Jul 2010 00:19:00 +0100 |
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
- Re: Auto-beaming infrastructure redo, (continued)
- Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/02
- Re: Auto-beaming infrastructure redo, Carl Sorensen, 2010/07/02
- Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/02
- Re: Auto-beaming infrastructure redo, Carl Sorensen, 2010/07/02
- Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/03
- Re: Auto-beaming infrastructure redo, Carl Sorensen, 2010/07/03
- Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/03
- Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/03
- Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/03
- Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/03
Re: Auto-beaming infrastructure redo,
Trevor Daniels <=
- Re: Auto-beaming infrastructure redo, Carl Sorensen, 2010/07/02
- Re: Auto-beaming infrastructure redo, Trevor Daniels, 2010/07/03
- Re: Auto-beaming infrastructure redo, Carl Sorensen, 2010/07/03
- Re: Auto-beaming infrastructure redo, Trevor Daniels, 2010/07/03
- Re: Auto-beaming infrastructure redo, Carl Sorensen, 2010/07/03
- Re: Auto-beaming infrastructure redo, Carl Sorensen, 2010/07/03
Re: Auto-beaming infrastructure redo, Hans Aberg, 2010/07/03