On 7/3/10 3:11 AM, "Trevor Daniels" <t.dani...@treda.co.uk> wrote:
>
>
> Carl Sorensen wrote Saturday, July 03, 2010 1:06 AM
>
>
>> On 7/2/10 5:19 PM, "Trevor Daniels" <t.dani...@treda.co.uk> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
