[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Beat grouping and reverting

From: Trevor Daniels
Subject: Re: Beat grouping and reverting
Date: Sun, 26 Oct 2008 22:44:03 -0000

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

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]