Re: Beat grouping and reverting

[Carl D. Sorensen]

On 10/26/08 4:00 AM, "Trevor Daniels" <address@hidden> wrote:

>
>
> Carl D. Sorensen wrote Saturday, October 25, 2008 11:14 PM
>> On 10/25/08 2:30 PM, "Trevor Daniels" <address@hidden> wrote:
>>> Neil wrote  Saturday, October 25, 2008 9:06 PM
>>>>
>>>> 2008/10/25 Trevor Daniels <address@hidden>:
>>>>> Carl
>>>>>
>>>>> But how do you revert entries like this:
>>>>>
>>>>> ((end * * 6 8) . #f) ;; switch-off at-any-beat feature
>>>>
>>>> The simplest way would be to add a function to switch this back on:
>>>
>>> I'd like to see the complex way  ;)
>>>
>>
>> What if we just removed all of the ((end * * num den) .#f) entries from
>> scm/auto-beam.scm?
>>
>> I tried it for 6/8, and I think things still worked just fine for me.
>>
>> It's not clear to me that these entries do anything useful with the
>> current
>> beatGrouping setup.  Perhaps they were needed with the previous code.
>>
>> How would we decide whether it's safe to remove them?
>
> I never did quite understand what these entries did.  My
> guess is that the (maybe previous?) code turned off beams
> at beatLength intervals by default, and these entries
> disabled that.  They only appear in the rules for the
> n/8 and n/16 time signatures, with beatLengths of 8 and
> 16, which supports that.

The current code will turn off beams at beatLength intervals, but only if:

1.  There is no explicit rule for the time signature
2.  There is no valid beatGrouping setting

Previously, the beatGrouping didn't work, so I could imagine that the
disable beatLength setting was necessary.  I think it is necessary no
longer.  When \time is set, beatGrouping is set as well, so things should
work properly even in the absence of explicit settings.  In fact, it may be
possible to greatly reduce (or even eliminate) explicit settings in
scm/auto-beam.scm and replace them with rules from beatGrouping.

Should I explore this further?

>
> It would be helpful if someone familiar with the previous
> working could confirm this, or perhaps someone using these
> rules or these n/16 or n/32 time signatures could edit
> scm/auto-beam.scm to remove them and see if it causes any
> problems.  I suspect it will not.

I agree.  But I don't know if such a person exists any more.

Carl