Urs,
Here's an old email that discusses a proposed different structure for setting
beaming characteristics.
The thing that caused me to see this as the most promising is it has settings
for both beat grouping (i.e. how to combine beamed notes into groups) and beat
subdivision (i.e. how to subdivide beat groups).
The proposal has never been fleshed out, but it at least has a placeholder for
the two different types of behavior we are after.
Thanks,
Carl
On 4/5/09, 3:35 PM, "Trevor Daniels" <t.dani...@treda.co.uk> wrote:
Carl D. Sorensen wrote Sunday, April 05, 2009 7:33 PM
> What if we scrapped the current auto-beam code completely, and
> replaced it
> with a structured beatGrouping, something like
>
> ((denominator (ending-beatGroupings) (subdivide-beatGroupings))
> (denominator2 (ending-beatGroupings) (subdivide-beatGroupings)))
>
> We might then have something like the following in 6/8 time:
>
> ((8 (3 3) ())
> (16 (6 6) (6 6))
> (32 (4 4 4 4 4 4) (8 8 8)))
>
> Then, if subdivideBeams were set to #t, we could reduce the beam
> count for
> a given level of beaming at the appropriate point.
>
> I don't know if this is a better solution, but it might improve
> what
> currently seems to me to be a very awkward system.
>
> One weakness in this approach is that it provides no way to have
> an
> auto-beam-ending rule for 3/32 beams (but I don't know of any 3/32
> beams, so
> I don't think that's a real limitation).
>
> David Brobroff's request
>
<http://thread.gmane.org/gmane.comp.gnu.lilypond.general/46316/focus=46323>
> could then be met by
>
> ((8 (4) ())
> (16 (4 4) ())
> (32 (8 8) (4 4 4 4)))
>
> This would have the downside of requiring a complete redefinition
> every time
> you changed the time signature, but it would get rid of the
> current problem
> where you have to revert rules before you can add new ones. It
> would also
> put all automatic definitions of autobeam rules in one location in
> the
> source tree, rather than having them spread across two files.
>
> I don't know if this proposal has merit or not, but it seems like
> we really
> ought to get to *some* combination of syntax and functionality
> that we think
> really works.
It definitely has merit! Let's see if I understand it.
The current (ie in 2.13.1) beam-ending rules are used
only to prevent long beamed runs of 16th and 32nd beams.
Your suggestion easily accommodates all these. For example,
in 9/4 time there are 16 rules to do this. These could be
replaced by the far simpler
\set beatGrouping =
#'( 8 (3 3 3) ())
(16 (4 4 4 4 4 4) ())
(32 (8 8 8 8 8 8) ()))
or rather the equivalent in scm/music-functions.scm. We
could even improve the default by using sub-divided beams,
something we can't do at present.
I can't see anything this can't do. If by 3/32 beams you
mean beaming 32nd notes in threes, I think it can do this.
For example, in 9/4 you'd need to modify the above to
\set beatLength = #(ly:make-moment 1 32)
\set beatGrouping =
#'( 8 (12 12 12) ())
(16 (16 16 16 16 16 16) ())
(32 (3 3 3 3 3 3 3 3 3 3 3 3) ()))
There was a discussion some time ago about auto-
beaming east-European rhythms. See
http://lists.gnu.org/archive/html/lilypond-user/2007-12/msg00032.html
It's getting late now, so I'll leave this until tomorrow,
but I wonder if your scheme would handle this?
Trevor
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
