Crowd-engraving? What’s that? (part 1)

If the “crowd editing” mentioned in the previous post made you curious, here you will find more information. Read on!

You can imagine that being a librarian of a semi-professional choir (by “semi-professional” I mean that our repertoire is quite professional, but we don’t quite make money by singing) can be a lot of work. Since we have limited funds, we try to use freely available scores, but often they are not available (or not satisfactory) and we have to prepare our own performance materials.

That was precisely the case with Handel’s Dixit Dominus (HWV 232), which we worked on during summer and autumn of 2012. We had found a free edition prepared by Philip Legge, but while it contained a conductor score and instrumental parts, there was no vocal score. So, despite all the work he had put in creating that edition, we couldn’t use it 🙁 – singing from a conductor score would be too cumbersome.  Neither could we adapt his work, because he had used proprietary Sibelius format which we were unable to open 🙁

How do you go about preparing a new edition of a piece this size, then? After all, it’s 40 minutes of music for SSATB choir and orchestra, and since we’re hobbyists, it means that no one’s getting paid for doing such work. If the conductor says “I need the 5th movement for the rehearsal next week”, you’re in trouble unless you have spare time at the moment… or divide the work.

The idea is simple: several choir members each copy a fragment of the movement. The tricky part is executing this smoothly: for example, let’s say that I create the file, set up headers and staves, and send it… to whom? Should it go to the person who’s going to copy the first sopranos’ part, or someone else? I could ask who will have time soonest, but that’s usually hard to know for sure (remember that we’re doing this in our spare time). So, that approach wouldn’t work.

Obviously, the answer was to use separate files – first soprano in one file, second soprano in another, etc. This way everyone worked on the part assigned to them, independently of others, and after the job was done the results could be copied-and-pasted into one file (and I would make any touch-up work that was necessary). The only thing that I didn’t quite like about this approach was the copying-and-pasting – it felt somewhat wrong to me, and there was a slightly increased chance of introducing errors.

Dixit Dominus p.1

Epifania version of Dixit Dominus (mvt.1) – click to download PDF

Fortunately, LilyPond offers a smarter way – you can link to the part files from a master file (it’s called ‘including’ in LilyPond, and you can read how it works in the documentation). Each of the part files continues to be an independent, self-contained description of respective voice, and at the same time another file combines them into full score.

This way, with the help of some fellow sopranos (these girls are really wonderful!) we created our own vocal score of Dixit (you can download the pdf of 1st movement by clicking on the image) – and even though it wasn’t meant for publication, don’t you think that it’s actually better-looking than the version created by Philip Legge using Sibelius?

And this is just the beginning…

8 thoughts on “Crowd-engraving? What’s that? (part 1)

  1. Pingback: An interview with Urs Liska | Scores of Beauty

  2. Piotr Suwara

    Do you post your music somewhere on the net, like Mutopia project? They accept pure lilypond 🙂

    You have most probably heard of recaptcha. How about re-music-captcha? There is some software which tries to read sheet music, maybe captcha-users would provide enough information about correct and incorrect guesses to translate scans of sheet music to lilypond?

    1. Janek Warchoł Post author

      Hi Piotr,

      posting this on Mutopia is a good idea! I wish I had more time so that I could do this (i haven’t contributed anything yet, so i don’t “know the ropes”). Right now i don’t have a second to spare 🙁

      As for recaptcha, the idea sounds interesting, but i don’t think it’s doable. Firstly, music notation is much more complicated than text – there are more symbols, they have totally different sizes, they can be arranged in multiple ways… Secondly, not much people have sufficient music-reading skills. I expect the results would be unreliable most of the time.

  3. Piotr Suwara

    Simoes and Almeida made a paper about publishing music (in an open source manner):
    They prefer to use abc format, they also present lyra format and seem to like chordpro format for chords. Can lilypond deal nicely with chords like chordpro does?
    Almeida, Carvalho and Oliveira wrote about Wiki::SCORE : , which can be found here: , it is used for collaborative writing.

      1. Janek Warchoł Post author

        Yes! What sets apart Distributed Proofreaders and Wiki::Score from our efforts is the nice web interface they have. We could really use that, but that’s something for the future.

    1. Janek Warchoł Post author

      Interesting reading!
      I’ve noticed that they must’ve written the music publishing paper quite a long time ago, since LilyPond syntax changed a lot (for the better) compared to the sample from the paper. I’ve sent them an email about it, as i believe that LilyPond would be much better than abc, since it’s similarly concise and readable (as opposed to MusiXTeX and MusicXML), and at the same time more feature-rich and supported by a more powerful notation engine.

      As for chords, LilyPond’s approach is quite different: chords aren’t attached to lyrics – both chords and lyrics have their durations and are aligned based on rhythmical information. So, while you can do all these things in LilyPond, it requires you to know the rhythms of the song more accurately. Maybe it could be possible to add a different “input paradigm” to Lilypond, but that would have to be thoroughly discussed with experienced devs.

  4. Pingback: Plain Text Files in Music | Scores of Beauty

Leave a Reply

Your email address will not be published. Required fields are marked *