Carl, you wrote Friday, December 18, 2009 4:21 PM
On 12/18/09 2:49 AM, "Trevor Daniels" <t.dani...@treda.co.uk>
wrote:
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.
The current design is that unless a beaming rule is specified for
a given
duration, the default beaming rule is used.
I mentioned this example because the beaming with
your patch is inconsistent when the 64th notes are
present because they cause the rule for 32nd notes
to be ignored. This is a change from the previous
behaviour.
For 2/2, the default rule is break at (1 . 2), with 1/32nds
breaking at
every (1 . 4). I'm not sure that this is the best possible rule.
After
all, I'm not an expert in beaming.
Me neither :(
Would it be better to have it follow the 4/4 rule: by default
break at every
(1.4), and have 1/8 notes break at (1 . 2) ? I expect that that
is what
Read is saying.
I don't have access to Read, but this from Ross may
guide us:
"In simple time any beat divided into more than two
parts cannot be connected to another beat [with a
beam] to form a unit." Now he doesn't say that the
converse is true, but maybe we can assume it is for
the default beaming. Hence in 2/2 we should not have
a default break every 4th - the default should be to
break on beats, ie at 1/2. We're left with the question
of what to do within a beat when 16th, 32nd or shorter
beams are present. Ross is silent on this point. But
I would suggest we treat them exactly the same - beam
to 1/2.
If so, this is a simple rule change.
Yes.
I think that the default rule set is probably not correct, and
needs a more
thorough reading. I'll try to get to that today.
OK. Maybe the best plan is to simplify where possible.
I think I might have been responsible for adding the
32nd rules, but I'm no longer sure this was wise in
some of the cases, like 2/2.
Carl
Trevor
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel