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!
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?
ReplyDeleteThe 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!
@Will:
ReplyDeleteI 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. :-)
@0xfe
ReplyDeleteJust 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.
Hello,
ReplyDeleteThis 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!
@Will: Thanks for the links. I've clearly got work to do :-)
ReplyDelete@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.
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.
ReplyDeleteAnyway, 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!!!
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.
ReplyDeleteThis is looking great! Please do release the code as soon as you can, even if it's incomplete.
ReplyDelete@Joe: Much appreciated :-)
ReplyDelete@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...
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