lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 638 in lilypond: auto-beam-settings do not take into account *


From: Alexander Kobel
Subject: Re: Issue 638 in lilypond: auto-beam-settings do not take into account *all* durations covered by the beam
Date: Sun, 29 Nov 2009 15:53:06 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

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.

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.


Thanks,
Alexander




reply via email to

[Prev in Thread] Current Thread [Next in Thread]