[Top][All Lists]

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

Beat grouping and reverting - proposed mod

From: Trevor Daniels
Subject: Beat grouping and reverting - proposed mod
Date: Tue, 28 Oct 2008 12:05:56 -0000

I'm starting a new thread for this, as the nesting in the
mails below is getting difficult to follow, and I want to
draw attention to this rather lengthy continuation.

In summary, neither Carl nor I believe that the entries
in the beaming rules in scm/auto-beam.scm which look like

((end * * 9 8) . #f) ;; switch-off at-any-beat feature

have any effect; Carl because he recently rewrote much
of the code and I because I've just extensively tested
the rules with and without these entries.  Carl's rewriting
(see  index 4757886..2b622fd 100644) removed the switch-
off-at-any-beat feature and replaced it with a rule to
end at a beat determined by beatGrouping and beatLength.
As it is already inactive, setting the entry to #f has no

1) So we propose removing these entries.  Please shout now if
you object to this.

There is further tidying required in scm/auto-beam.scm:-

2) The rules for 12/8 are incomplete.  There is only one
entry for 1/32 beams, at the 1/8 position.  This should
either be removed, or a complete set of entries for
1/32 beams added.  So what beaming should be provided by
default for 1/32 beams in 12/8 time?  Composers to answer

3) Even more.  The rules permit the starting point of
beams to be defined, but this seems quite ineffective.
The present algorithms assume beams can start at any beat.
For now I've changed the docs to reflect this, but at
some time this whole syntax needs to be reviewed.  But I
do not propose we should do that this side of 2.12.


Carl D. Sorensen wrote Monday, October 27, 2008 12:03 AM

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

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.


reply via email to

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