Re: Issue 638 in lilypond: auto-beam-settings do not take into account *all* durations covered by the beam

[Carl Sorensen]

On 11/29/09 7:53 AM, "Alexander Kobel" <address@hidden> wrote:

> address@hidden wrote:
>> Comment #7 on issue 638 by percival.music.ca: auto-beam-settings do not
>> take into account *all* durations covered by the beam
>> 
>> I think this is the autobeaming issue that Carl's working on.
> 
> 
> Hi, Carl,
> 
> from what I understand from Graham's remark it is you who's working on
> beaming?
> If so, perhaps you can help me with the following and/or include it in
> your thoughts and implementation.
> 
> I have a few pieces where I want use beams to denote melismata . On the
> other hand, for some longer melismata - often also including quarter or
> half notes - which I specify with slurs, I want the usual automatic
> beaming take place inside.

Why not just use \melisma and \melismaEnd?

> 
> Now, it's awkward to always write ([ ]), when essentially ( ) already
> implies what I want. So, a straightforward idea was to leave auto
> beaming activated, and try a function like this:
> 
> INPUT: music m
> 
> slurred = false
> for each chord c in m {
>    if (c contains a "(" [slur-begin]) {
>      slurred = true
>      add forbid-beam-to-the-left to c
>      add allow-beam-to-the-right to c
>    } else if (c contains a ")") {
>      slurred = false
>      add allow-beam-to-the-left to c
>      add forbid-beam-to-the-right to c
>    } else {
>      if (slurred) {
>        add allow-beam-to-the-left to c
>        add allow-beam-to-the-right to c
>      } else {
>        add forbid-beam-to-the-left to c
>        add forbid-beam-to-the-right to c
>      }
>    }
> }
> 
> Alas, the problem is: the allow-beam-* and forbid-beam-* are
> nonexistent, AFAICS. \noBeam outside of the slurs destroys the auto
> beaming from the last possible beam start position to this point, which
> may influence notes in the surrounding melismata; and something like
> just adding [ to ( and ] to ) gives stub beams also in cases like { c8([
> c4 c8]) }, where I actually want flags.
> 
> 
> So, my question is: how much effort would it take to have such a
> allow-beam-* or forbid-beam-* functionality?
> I also could imagine a \splitBeam command, which forbids a "bridge beam"
> between the preceding and the following note:
> 
>    { c8 c c c c \splitBeam c c c }
>      ==========  |  =======
>      |  |  |  |  |\ |  |  |
>      |  |  |  |  |  |  |  |
> 
> Then, the code for my function would look like
> 
> slurred = false
> for each chord c in m {
>    if (c contains a "(" [slur-begin]) {
>      slurred = true
>      insert \splitBeam before c
>    } else if (c contains a ")") {
>      slurred = false
>    } else {
>      if (! slurred) {
>        insert \splitBeam before c
>      }
>    }
> }
> 
> Hell, even simpler. But - as I said - I have no idea of the work
> involved in this. It'd be great if you think about it, though.

None of this functionality is currently in autobeaming, AFAICS, and I don't
think that I'm going to try to implement it in the near future.  My interest
in autobeaming isn't that high.  I just want to get the current bug fixed
(and then maybe I'll try to get subdivide working, if I can ever figure out
just what that means).

If you'd like to work on this, I'll be happy to share what I know about
autobeaming with you.

Thanks,

Carl