Carl, you wrote Monday, August 10, 2009 10:58 PM
On 8/10/09 9:14 AM, "Trevor Daniels" <[email protected]>
wrote:
With all Carl's mods applied just the expected two
inconsistencies
remain:
\relative c'' {
a8 a a16 a a8 a a a a16 a | % wrong, should be ...
a8 a a16[ a a8] a a a[ a16 a] |
a32 a a16 a a a a32 a a16 a a a a32 a a16 a a a a32 a | %
wrong,
should be ...
a32[ a a16 a a] a[ a32 a a16 a] a[ a a32 a a16] a a a a32 a
}
The second of these can be fixed (bypassed really) with
\overrideBeamSettings #'Score #'(4 . 4) #'end #'(((1 . 32) . (8 8
8
8)))
which I think is a more acceptable beaming anyway,
but the first is a more fundamental problem which cannot be
fixed by any override which preserves beam breaks at
1/4, 1/2 and 3/4 AFAICS.
OK, so now I can see the differences. Thanks, Trevor.
Can you express in words a rule that describes why
a8 a a16[ a a8] a a a[ a16 a16]
is better than
a8[ a a16 a a8] a8[ a a a16 a]
? It seems to me that something has triggered a desire to break
the beam on
the beats, when
a8[ a a a] a[ a a a]
is desired to break at 1/2.
Perhaps if you can explain this, I can figure out what is missing
in the
autobeaming algorithms.
I can do no better than quote Ross:
1. [in 4/4 time] "A beam can never be used
to combine notes of the second and third
beats into a unit."
2. "In simple time any beat divided into
more than two parts cannot be connected
to another beat to form a unit."
Apart from these there are no firm rules,
but these explain my beaming. Rule 1 permits
beaming 4 quavers (sorry, 8th notes) together
(and this seems the common practice), as
quavers have only two parts to a beat, but as
soon as two 16th notes are introduced we have
(at least) three parts to a beat, and rule 2
kicks in, forcing beams to be limited to
single beats.
HTH
Trevor
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
