lilypond-user
[Top][All Lists]
Advanced

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

Re: auto-beaming


From: Trevor Daniels
Subject: Re: auto-beaming
Date: Thu, 19 Mar 2009 17:56:51 -0000


Carl D. Sorensenwrote Thursday, March 19, 2009 2:42 PM

On 3/19/09 8:34 AM, "Mats Bengtsson" <address@hidden> wrote:
Carl D. Sorensen wrote:

On 3/19/09 5:13 AM, "Mats Bengtsson" <address@hidden> wrote:

Should we turn this into feature request to make the automatic
subdivision of beams even more flexible, with separate rules for different note lengths, or would the resulting scheme get too messy to
use and implement?

It seems to me that this should be a feature request.

It also seems to me that we could make this quite easy to use as a default.

We currently have beatGrouping used to end beams and beatLength used to
subdivide beams.

If we want more control over ending beams, we use override-auto-beam-setting
to add beam endings for specific beam types (16th, 32ned, etc.)

We should be able to add a functionality for override-beam-subdivision that is beam type specific, just like we've done for beam endings. Although it may be somewhat hard to get just right, the documentation is in *much* better shape than it used to be (thanks, Trevor), and we can use a
corresponding syntax so it must only be learned once.
You mean, using
#(override-auto-beam-setting '(subdivide 1 32 3 4) 1 8)
to get a subdivision after the first four 32nd notes in 3/4 meter? Good
idea!

Actually, that's not what I meant. But it's what I should have meant. So I guess I should have meant that. I'm glad people smarter than me are around
to pick up the pieces!

I'd go along with this.  If the new subdivide rules didn't
inhibit the beatGrouping rules it would make it easier for
users to override the defaults, since we could remove some
of the beam-ending rules and replace them with subdivide
rules and still get acceptable beaming out of the box, with
fewer reverts being needed.

BTW, did we ever file a feature request for a function to
revert all the beam-ending rules in a particular time
signature?  This would also be very useful.

Trevor






reply via email to

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