Re: Beat grouping and reverting

[Trevor Daniels]

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
> > > > > 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

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.

> 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.

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.

> 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.

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.

Trevor