Re: Beat grouping and reverting

[Carl D. Sorensen]

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

>
>
> Carl D. Sorensen Sunday, October 26, 2008 9:30 PM
>> 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
>>>>>>
>
>> 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
>
> If you're sure about this then the switch-off-at-any-beat feature
> is now redundant, as it occurs only with other rules which will
> inhibit turning off beams at beatLength intervals anyway.

I'm sure about the rules, because I programmed them in (of course, I won't
guarantee they're bug-free, but I think they are).  I do need to clarify
rule 1.  It should read "There is no explicit rule for the beam-length in
the time signature."

>
>> 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 should
>> work properly even in the absence of explicit settings.
>
> I agree this seems very likely; let's assume it is true.
>
>> 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.
>
> No, I don't think so.  The rules are beam-duration-dependent;
> beatGrouping and friends are not.  This is used to good effect
> in the rules for pretty well all the time-signatures.  So I think
> we have to retain the rules but without the switch-off-at-any-beat
> rule.

We could at least eliminate all the rules that are covered by the default
beatGrouping, and it would make that many fewer rules to revert.

I agree with you about the beam-duration dependent rules -- they need to
stay to keep the current behavior.

>
> Also, if the time signature changes frequently between, say, 3/8
> grouped (3) and 6/8 grouped (3 3) you'd need to reset beatLength
> at every change from 1/8 to 3/8 (correct me if I'm wrong).  With
> the rules you could set this up once for each time signature and
> no further changes would be needed.

3/8 and 6/8 both have a beatLength of 1/8, so I belive that no change is
necessary in the scenario you propose.  However, as I look at the default
beat groupings (found in scm/music-functions.scm) I see that, although there
is a default beat grouping of (3 3) for 6/8, there is no
default beat grouping of (3) for 3/8.  It would be trivial to add it to
scm/music-functions.scm.  If this were done, there would be no need to do
anything but switch the time signature.

Of course, one could always set up explicit rules to cover a particular time
signature, and those rules would be persistent.

>
>> Should I explore this further?
>
> Actually I think the most useful thing would be an override
> which would switch off all the rules for a particular time
> signature, so enabling the simpler beatGrouping to work for
> any of the common signatures as well, if desired.

It should not be too difficult to write a scheme function to revert all
rules for a given time signature.  I think that's something that would be
very useful.  Perhaps while I'm on travel next week I'd have the time to
give it a shot.  In the meantime, I would guess that Neil or Nicolas could
do it in just a few minutes.

>
> I'll spend a little time tomorrow playing with turning off
> the switch-off-at-any-beat feature to try to convince myself
> it is now redundant, with a view to removing it in the next
> 2.11 release.  That at least will tidy things up a bit, and
> make it possible to revert all the rules easily, if laboriously.
>

If we can prove that switch-off-at-any-beat is now redundant (and we may
need to add some default beatGroupings to make it so), we at least avoid the
problem of having a nearly-impossible-to-revert setting.

Carl