I've been studying the auto-beam code to try to get to the core of what's
wrong with it, and I think I finally have it resolved. Let me describe the
issues that I see.
1) There are three different kinds of signals for ending auto-beams.
A) beatLength -- end a beam on the end of a beat
B) beatGrouping -- end a beam on the end of a beat group
C) auto-beam-setting -- end a beam when the auto-beam-setting says to.
These three different ways are potentially confusing, but we currently have
the code that handles all three. All three can peacefully coexist, and, in
fact, all three are apparently used in the default auto-beam behavior.
However, there is a problem in that auto-beam-setting and beatGrouping are
initialized and set in two different places.
2) There is an infinite number of auto-beam-setting values that can apply in
any time signature. This is in contrast with every other LilyPond property
with which I am familiar. With auto-beam-settings, when you add a new
setting it doesn't replace the old setting.
I think point 2 is the major source of confusion in using
auto-beam-settings. The user tries to create a new auto-beam-setting, but
forgets (or doesn't know) to revert an pre-existing setting. Then, since
both settings apply, the behavior seems arbitrary to the user.
I would like to propose that we do the following:
1) Eliminate all documentation and snippets using beatLength for controlling
automatic beaming.
2) Eliminate beatGrouping for controlling automatic beaming
3) Convert auto-beam-settings to a property alist. The key would be
'(type time-signature-numerator time-signature-denominator)
For now, type would be limited to 'end (which is the current status). In
the future, following up on Mats's (or was it Kieren's?) excellent
suggestion, we would implement 'subdivide.
The value for the alist would be another alist. This alist would have
entries for individual beam durations, as well as a possible entry for * as
a beam duration.
So we might have default-auto-beam-settings be something like
`(
((end 2 2) . ((* . (,(ly:make-moment 1 2) ,(ly:make-moment 2 2)))
(32 . (,(ly:make-moment 1 4) ,(ly:make-moment 2 4)
,(ly:make-moment 3 4) ,(ly:make-moment 4 4))))
((end 6 8) . ((32 . (,(ly:make-moment 1 8) ,(ly:make-moment 2 8)
,(ly:make-moment 3 8) ,(ly:make-moment 4 8)
,(ly:make-moment 5 8) ,(ly:make-moment 6 8))))))
A '*' entry would apply to all beam lengths that weren't explicitly
specified.
The auto-beam rules that are currently handled by beatLength and
beatGrouping would be handled by the '*' entry.
In order to make it easier to do the override, I'd make a function
(make-auto-beam-setting setting-key setting-alist)
where setting-key would look like
'(end 2 2)
and setting-alist would look like
'((* . ((1 . 2) (2 . 2)))
(32 . ((1 . 4) (2 . 4) (3 . 4) (4 . 4))))
The function would convert the cons cells into moments, so that the moments
wouldn't have to be recalculated every time a beam is calculated.
By making auto-beam-settings a regular alist, we should be able to do
regular \override and \revert calls.
By putting the whole set of autobeam settings of one type into a single
alist, it would take only one call to set the autobeaming however it is
desired for a given time signature.
By having the time signature in the auto-beaming-list and avoiding the use
of beatGrouping, we can avoid having settings that affect autobeaming in the
time signature change code; a change in time signature will automatically
change the autobeam settings.
Does this proposal seem reasonable?
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
