Colin Hall <[email protected]> writes: > On Mon, Jun 25, 2012 at 07:15:53AM +0200, David Kastrup wrote: >> Colin Hall <[email protected]> writes: >> >> > On Mon, Jun 25, 2012 at 12:38:34AM +0200, David Kastrup wrote: >> >> Nick Payne <[email protected]> writes: >> >> >> >> > If I set beamExceptions to beam 32nd notes by fours in 4/4 time, this >> >> > has the side effect of changing the beaming of 8th notes: >> >> > >> >> > %===================== >> >> > \version "2.15.40" >> >> > >> >> > changeBeaming = \set beamExceptions = >> >> > #'((end . (((1 . 32) . (4 4 4 4 4 4 4 4))))) >> >> > >> >> > \relative c'' { >> >> > c8 c c c c c c c >> >> > \repeat unfold 32 { c32 } >> >> > } >> >> > \relative c'' { >> >> > \changeBeaming >> >> > c8 c c c c c c c >> >> > \repeat unfold 32 { c32 } >> >> > } >> >> > %===================== >> > >> > Thanks for the report, Nick. >> > >> > I just checked the docs, Nick, and I agree with you that: >> > >> > "Beaming-rules is a scheme alist (or list of pairs) that indicates the >> > beam type and the grouping to be applied to beams containing notes >> > with a shortest duration of that beam type." >> > >> > would lead me to expect that an exception that only mentions 32nds >> > would only apply to 32nds. >> >> It does. But if he _replaces_ the existing list, previously entered >> exceptions are cleared out. > > Thanks, David, that makes it plain. > > I've re-read the docs and here is my new understanding: > > Common time has already established some exceptions to the beaming > rules, which is why Nick's first bar is beamed in groups of four 8th > notes in the first place.
Well, it may be problematic that we don't have a user-accessible way of telling LilyPond "please _add_ to the current exception list". To do that, one would need separate lists for "system exceptions" and "user exceptions", and then one would also need a way to say "please forget the system exceptions". Ok, possibly in this case just explicitly reentering the on-beat behavior for 8th notes would do. > I think the source of my confusion (and perhaps Nick's also) is that > the norm, to which we are creating an exception, is unclear. > > He and I assumed that the normal behaviour is "what Lilypond does if I > make no special statements about beaming" whereas what normal actually > means is "terminate a beam at the end of a beat." > > The behaviour of Lilypond does agree with the documentation so there's > no bug here. Setting/overriding whole lists when the default is non-empty is probably not leading to the most convincing user interfaces. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
