Our regular readers must have noticed that our “blogging schedule” is recently quite spotty – we apologize for that! There’s a lot of things that are keeping us busy, and one of them is very important news for LilyPond – we’re going to announce it this Tuesday, be sure to drop by! 🙂
Anyway, I’ve recalled that I had written one more post draft about our Fried project, and I’ve decided to finish it because this information may be interesting for you: it’s the concluding statistic – the timing of my work.
So, how efficient time-wise is LilyPond in real-life usage? Fortunately, for the last 8 songs (out of 26) I’ve been measuring the time spent during the “beautification” process. Since we were using version control, I had a convenient place to store this metadata – commit messages:
916b88d 8-1 beautification: missed one extender (14 min) b136ddb 8-1 beautification: fix lyric extenders (10 min) ace7661 8-1 beautification: lyric alignment (7 min) ac07f8d 8-1 beautification (20 min) a7a776d 8-1 beautification: mostly slurs (10 min) 010b1e8 8-1 beautification: mostly slurs (18 min) e769159 8-1 beautification: slurs (20 min) 02b39f7 8-1 beautification: slurs (15 min) b060a9b 8-1 beautification: slurs (37 min) f817400 8-1 beautification: fix melisma alignment (12 min) 5c9262b 8-1 beautification: slurs (17 min) a6ce7af 8-1 beautification: fix voicing (14 min) 454bc2d 8-1 beautification: slurs (22 min) d091a89 8-1 beautification: slurs (42 min) 32c0e18 8-1 beautification: cross-staff, last system (25 min) c6baaef 8-1 beautification: mostly beams (11 min) 17d665b 8-1 beautification: ties (53 min) a03d4a5 8-1 beautification (5 min) 55c4edc 8-1 move 3rd stanza metronome mark (4 min) 2661429 8-1 beautification: squashing to fit system (40 min) a14f4e7 8-1 beautification: metronome mark (6 min) 7cbec4a 8-1 beautification: dashed slurs (10 min) c38d7a5 8-1 fix lyrics alignment (was caused by a typo) (5 min)
Based on the data I gathered, average beautification time for this type of music is 85 min/page. In addition to the actual work there is always maintenance time (discussing non-trivial issues, either via email or using an issue tracker, managing the code etc.) which I estimate to be something like 32 min/page. And, of course, there is also the time needed for the input of the musical content, but unfortunately I don’t have data about this.
Taking into account additional time initially spent on discussing and setting the project up, as well as extra maintenance time lost when we hadn’t switched to version control yet – I estimate this to be about 45 hours, but it’s a very uncertain guess – we arrive at a figure of 230 hours for the beautification of all scores. Since I wasn’t timing my work in the beginning, I estimate the uncertainty of this number to +/- 30%, with 90% confidence.
230 hours translates to 6 weeks of full-time work to beautify the raw output for roughly 100 pages of music. Is this result good or bad? It’s difficult to judge without information on how other notation programs (and other engravers) would perform on similar music. I would say that 230 hours is unsatisfactory – particularly measured against LilyPond’s claim of automatic music engraving. This seems still far away, at least in the case of complex piano music.
However, we should keep in mind that for both me and Urs this was the first project of this size. I expect that with the gained experience a follow-up project would be completed about 25% faster.
As you can see in the commit listing above, I have tried to group different types of fixes together – for example, commit slur changes separately from lyrics changes and so on. This allowed me to calculate average times needed for adjusting a curve – they are:
- 1.5 minute per slur
- 1 minute per tie
In total, I estimate that shaping slurs and ties took about 40 hours, i.e. 25 minutes/page of music. This is 30% of all time needed for beautification – as I’ve said, it’s probably the most time-expensive part of the beautification process! It is good to know that there are improvements at the horizon, most notably the prospect of being able to edit curves graphically in Frescobaldi in the foreseeable future.
As a “post-scriptum”, I have to mention a small annoyance that, unfortunately, appears in all projects engraved using LilyPond: having to wait while the score recompiles. This is insignificant when preparing a small piece, but when dealing with a bigger project, it results in some wasted time. Fortunately, I have just recently bought a fast laptop, and the whole Fried project consisted of many short pieces (1-8 pages each), so the recompilation times were usually in the range of 3-9 seconds. But even these seconds piled up and contributed to the total time spent. What’s more, they affected my workflow – since I did have to wait before seeing the results of my adjustments, the working process wasn’t as smooth as it could be. This may seem insignificant, but I do believe that if the times of compiling LilyPond scores went down from the rage of 5-50 seconds (for the not-so-big pieces) to the range of 0.1-1 seconds, it would mean that the experience of working with LilyPond would be totally different. And by different I don’t simply mean faster and therefore better – I mean that this would be a qualitative leap that would allow us to work in completely different, more natural ways. As an intermediate workaround we will have to look for ways to recompile only smaller parts of the complete score, the ones we’re actually interested in.
I could now write a long elaboration on this topic, but since it was already covered by smarter and more experienced people than me 😉 , let me just recommend you looking at Linus Torvalds’ talk about Git and this article written by Joel Spolsky, an influential IT blogger.
See you again on Tuesday when we’ll bring this series of posts about Oskar Fried to a – preliminary – end! 🙂