Re: autoBeamOff bug

[Russ Ross]

I tried fixing this problem with mixed results.  This small patch to
lily/auto-beam-engraver.cc:

267c267,268
<       if (b)
---
>       bool on = to_boolean (get_property ("autoBeaming"));
>       if (b || !on)

did the job in most instances, but it happened to fail in the first
case I tested, which included an \autoBeamOff immediately followed by
\autoBeamOn.  I was hoping to be a break in the beaming at this point,
but since the "autoBeaming" property had been updated twice by the
time the consider_end function was called, it amounted to a no-op.

In vocal parts, autobeaming generally coincides with melismata.  I
usually turn autobeaming off so that a single word or syllable matches
a single, unbeamed note.  When a word is held, I turn on a melisma and
I also turn on autobeaming, which matches the conventions of my source
manuscript  (Bach).  Because this is so common, I use a shorthand in
my own work, namely [[ to start a melisma/autobeaming group, and ]] to
end it.  Then I run a perl script to expand those into the
corresponding lilypond commands as part of my build process.

This leads regularly to the situation above, where one melisma group
is followed immediately by another, which manifests itself as
\autoBeamOff followed directly by  \autoBeamOn.  Note that \noBeam
isn't suitable here, as the notes on both sides may be in beaming
groups.

Is there a way to work around this?  Or better yet, a way to fix it? 
It seems like autoBeamOff needs to trigger some kind of an event
rather than just setting a property.

Also, what do you think of adding syntax like what I've described to
better support vocal music?  "a8[[ b c]] d" is much more pleasant than
"\autoBeamOn a8\melisma c b\melismaEnd \autoBeamOff d", and it is
pretty common in vocal music.

Thanks,

Russ


On Mar 30, 2005 10:25 PM, Russ Ross <address@hidden> wrote:
> There seems to be a bug in \autoBeamOff.  If it is issued in the
> middle of a sequence of notes that would be beamed together, it
> doesn't take effect until after the end of that group.  It seems that
> the correct behavior should be to stop automatic beaming at the point
> where the command is issued.  It poses a particular problem for me
> with some (partially) generated input.
> 
> Here's an example showing the problem:
> 
> \version "2.5.15"
> \score {
>   \relative c' {
>     \autoBeamOn d'8 cis d b cis b cis ais |
>     b ais b d~ d \autoBeamOff cis d b |
>   }
> }
> 
> The final "d cis d b" sequence is beamed in the current code, but it
> shouldn't be.
> 
> Thanks,
> 
> Russ
>