Monday, June 07, 2010

On Beams

Beams are interesting. Engraving rules for beams are extremely inconsistent. In essence, the ideal rendering involves striking a balance between the direction of the music, the angle of the beam, and the length of the stems. You don't want beams whose absolute slopes are too high, and you also don't want to compromise on the slopes too much by making the stems too long.

There is one well-known rule, however: Never shorten a stem.

Beams on Both Voices

The algorithm I currently use to render beams seems to work pretty well. I use an approach where I iteratively update the slope and y-shift of the beam, based on the height of each stem.

In retrospect, this algorithm seems pretty obvious, but I really had to experiment a fair bit to derive it. The first few beams were just all over the place.

Beam Confusion

More Beam Confusion
My debugging code places colored dots at various control points to help me visualize the errors better. It took me a bit of effort before I got to the rendering below. The beams still aren't shifted far enough to both accommodate for the stem heights.

Close... But Still Wrong!

After ironing out the iterative algorithm, I got this:

Decently Rendered Beams
Perfect! The stems are only extended where necessary, and the angles of the beams adequately reflect the direction of the music.

Thanks to the context-based architecture, note-modifiers such as accidentals don't disturb beam positioning.

Beam With Accidentals
That said, something about the above rendering does not look right to me. The group of eighth notes don't look like they're positioned very evenly. If anyone knows how to render beamed notes with accidentals correctly, please let me know.

Anyhow, I also got slides and ties working again. These were gone after the rewrite, and I had to work them in using the new framework.

Tab Slides
Hammer-Ons

These actually make use of annotation-contexts which help determine the position of the annotation text above the stave.

Random Annotation

I'm still a bit unsure of how to render ties across different note steps, with accidentals. What I have now looks like this:

Chord Ties
Although this is a really uncommon case, it would be nice if there were a generic way to deal with it. Thoughts? Ideas?

That's all for now folks, and thanks very much for the comments. Keep 'em coming!

10 comments:

  1. I'm really impressed with the rendering you put together for the beaming, as you said it's something that isn't consistant, and you did a great job. One question is how to deal with rendering beams for notes that cross from one staff to the other, starting in the bottom and continuing into the top staff? Or runs that have a very large range between the lowest and highest notes?

    The tie method between chords is a difficult topic to find a definitive answer. I like the bent method, but not sure classical musicians will approve. It's very readable, but I'm not that strict on standards. The extension of that is dealing with tying notes of different durations to a chord that follows, lots of overlaps to deal with. Just some food for thought. Keep up the great work!

    ReplyDelete
  2. @Will:

    I haven't really thought about beams across staves, but I think it should be pretty straightforward to support for two staves. (I hope beams don't usually go across more than two staves, because that will be pretty tricky.)

    Re: large ranges, I tend to prefer high slopes to lengthening stems. (I'll update this post with an example shortly.)

    Thanks for the comments, much appreciated. :-)

    ReplyDelete
  3. @0xfe

    Just for your reference:
    http://img485.imageshack.us/img485/4071/beamsjh0.png
    http://www.turandot.hu/Images/cross_staff1.gif
    http://www.lilypond.org/doc/v2.12/input/regression/92/lily-b035726f.png

    Can't seem to find an example of the tied chords I mentioned. I've seen it in the printed music I've used, but dont have any with me to scan.

    ReplyDelete
  4. Hello,

    This is very good and encouraging work and I'm really happy to see that you want to deal with complex details. Have you thought about how to handle beams on the staff and how they will be positioned relatively to the lines in the staff? Especially for shorter notes, the staff lines can make reading harder if the beams are not carefully positioned. This is a simple example: http://i.imgur.com/p732J.png

    Hope this helps in some way, keep up the good work!

    ReplyDelete
  5. @Will: Thanks for the links. I've clearly got work to do :-)

    @raf: I haven't really thought about positioning relative to staff lines, but thanks for bringing it up. I'm going to experiment with some cases where the beams interfere with the staff, and see if I can come up with a general solution.

    ReplyDelete
  6. Awesome stuff! I remember seeing a copy of a handwritten manuscript by Bach were he used the shape of the beams to indicate phrasing. They would sort of swoop as he intended the phrase to. I would guess that printing music mechanically had something to do with that practice being phased out.

    Anyway, If you have plans to open source this project I will be a ready contributor, and if you plan to sell it commercially I'll be your first payer. Great work!!!

    ReplyDelete
  7. Have you seen the way Guitar Pro 4 and below are using the tablature notation? For some reason they removed it in versions 5 and 6 but the early notation was with staffs below the tabs, which I still find very usefull.

    ReplyDelete
  8. This is looking great! Please do release the code as soon as you can, even if it's incomplete.

    ReplyDelete
  9. @Joe: Much appreciated :-)

    @Tails: Screenshots? Is it the fact that the staves are _below_ the tabs that you find useful? If that's the case, the API allows you to position the staves where ever you like.

    @Rein: Thanks... I'm crunching away...

    ReplyDelete
  10. Regarding the chord ties, aren't ties supposed to go to the same note? If you mean slurs then you only need one slur for the whole chord.

    ReplyDelete