[Le Site]

The LilyPond Report #18

Valentin Villenave — 2010-05-12T17:04:30Z

Welcome to this eighteenth issue of the LilyPond Report !

This issue will be filled with emotion and coolness, paper bags and zigzag-ending staves, plus the usual Frogs and Bugs. As always, you are warmly invited to post comments at the bottom of the page, or even contribute to the LilyPond Report's next issues, by contacting Valentin or Graham.[sommaire]

Editorial

(by Valentin Villenave)

Greetings,

yesterday I was interviewed by a student who's writing a thesis about Free Software. Explaining why one contributes to Free Software is not always easy, particularly in a world where we were led, for the past two-and-a-half centuries, to believe that working has to be boring, unpleasant, and rewarded only with money. (Yes, that was my social-alienation-theory of the week, bear with me. :) )

The LilyPond project is the first (and only) Free Software project I've been involved with, so I probably lack comparison material, but nevertheless I have the feeling that our community has a very specific charm : perhaps because we're all musicians ? Although I've never met so many people both talented and smart, what strikes me everyday is the dedication and patience of these people — of course, there are many ways of being kind, some of which may take a while to get used to...

Why contribute to LilyPond ? Personally speaking, I began contributing as a way of showing my gratitude to these aforementioned people. I continued contributing because this gratitude somehow turned into friendship (with a hint of pride : hey, I'm hanging out with the cool kids now !). And eventually, at some points I stopped contributing, mainly out of guilt for not being able to be as clever, brave and competent as the rest of us.

Of course, I could hardly speak for other contributors. But how come that leaving this project is so hard, even seemingly impossible, to leave the LilyPond project for good ?

There's an untranslatable French expression for these exceptionally fine dishes or wines one can't stop asking to be served : "it tastes like revenez-y". Surely, we must do something right, don't we ? :-)

Release news

(by Graham Percival)

The current stable release is 2.12.3-2 ; all normal users should be
engraving with this version. We have no plans on making any more
2.12 releases.

The current development release is 2.13.20. This version has 10
Critical issues, with patches pending for 2 of them. The release
is slightly closer than it was when the previous Report was
published, but not much. In particular, issue 989 (ensure that no
information is only in the regtests) has received almost no
attention. This is saddening, since it's the easiest issue for
normal users to help with.

Oh well ; if users don't particularly want 2.14 any time soon, then
I shouldn't get worked up about it either.

In short

(by Valentin Villenave)

– Hey, look : Wikipedia has updated its webdesign before us ! Is it a success ? Well, let's have a look at the talk page :

Leave it alone I like it the way it is. don't mess with it. WKIPEDIA IS NOT SO GOOD AS IT WAS wikipedia has grown dull -thus people are not attacted to it.i wish you should improve it,

Is that the kind of reactions we have to expect when we finally release our own new design ?

– Hey, look : the new (lovely) companion of Doctor Who

Ouverture pour deux pianos, sur le nom d'Anne-Marie de Lavilléon-Verdier

Licence CC-by-sa © Valentin Villenave, 2004-2010

is named... Amy Pond. Sounds familiar ?

(And, no, don't ask how comes a French LilyPonder knows about the very latest episodes of an UK-based TV show. Just, don't.)

– Andrew Hawryluk has established an interesting comparison of LilyPond's font vs other music fonts. Nice !

– fred@ is no longer with us. This mysterious contributor, whom very little is known about, had signed every commit from our (dark, ancient) pre-git times ; these commits are now properly attributed. Goodbye fred@ !

– So let me get this right : it took us three days, and more than twenty mails, to come up with a name for the bug-handling team : the bug squad !

Well done.

Nobody else had ever, ever thought of it :-)

Conference sightings !

(by Valentin Villenave)

Reinhold appeared at the Linux Audio Conference in Utrecht /
Netherlands, presenting two papers :

- R. Kainhofer : A MusicXML Test Suite and a Discussion of Issues
  in MusicXML
- R. Kainhofer : OrchestralLily : A Package for Professional Music
  Publishing with LilyPond and LaTeX

As Reinhold told us :

Both are connected with LilyPond, the first one since the test
suite was originally written as regtests for the musicxml2ly
converter, but has now reached a state where it is useful also for
several other projects. Also, the suite is still in lilypond's git
master in the directory input/regression/musicxml2ly.

And the second paper obviously presents my orchestrallily package
and shows off some beautiful scores produced with lilypond.

Both papers can be downloaded from my homepage.

Graham Percival will be at the international Libre
Software Meeting 2010 in Bordeaux, France, running from 6 to 11 July 2010. John Mandereau, Valentin Villenave, Nicolas Sceaux and Francisco Vila will be attending as well ; Graham will be giving a lecture entitled : Sustainability in Free Software — Developers as a non-renewable resource. Here's the pitch :

The time and energy which developers spend on open-source projects is not an infinite resource. Developer effort can stall due to external demands on their time (such as family, career, or health), but also due to internal factors (such as a loss of motivation or interest). Long-term projects (5+ years old) should try to engage in sustaindable development practices. How can we retain developer interest ? How can we prepare for the inevitable loss of developers ? How can we train the next generation of developers ?

The LilyPond community definitely can relate to that : for the past couple of years, perhaps our main goal has been to make sure that the LilyPond project can go on as the original lead developers have less and less time to invest in it.

Graham has been at the heart of this perpetuation process : in 2008 with the Grand Documentation Project, that aimed to involve as many people as possible to write better and more maintainable documentation ; in 2009 with the Frogs, a bug-fixing task-force magically turning normal people into full-blown, hardcore developers (at least that's what it looked like from the outside :) ), and in 2010 with the Grand LilyPond Syntax Stabilization Project, that will hopefully bring us a stable, reliable syntax for the next decade or so.

Wow.

Whilst "developers" certainly are a "non-renewable resource", we do need more people like Graham, who are vital to a Free Software project even though they may not write a single line of code code (actually he does, but you get the point).

Paper-Baggers

(by Graham Percival)

When young children are embarrassed, many hide their faces —
trying to hide from the outside world. Well, many LilyPond
Developers are still children at heart, and wear brown paper bags
over their heads when they screw up.

"Ballade pour un mois de mai", pour flûte et piano

Licence CC-by-sa © Valentin Villenave, 2003-2010

22 March 2010,
Han-Wen

Neil wrote :
> Your first patch from the set you've pushed breaks the
> positioning of fetaText glyphs, since they now all have logical
> extents in the Y axis (rather than ink extents).

Ouch - can someone pass me the brown-paper bag ?

27 March 2010,
Jan

Subject : hold your horses, new repo #3 ETA 1500 CET

Han-Wen, you're ready to hand me the brown paper bag ?

29 March 2010,
Graham

The attached patch, plus the attached brown-paper-bag-for-Graham
discussion on IRC, points to a solution.

IRC discussion :

(16:02:12) janneke: import langdefs; for lang in langdefs.LANGUAGES: ... (16:02:41) gperciva: File "../lilypond/scripts/build/create-weblinks-itexi.py", line 11, in  (16:02:41) gperciva: import langdefs (16:02:41) gperciva: ImportError: No module named langdefs (16:02:48) janneke: try: (16:02:59) gperciva: remember, we DO NOT COMPILE SCRIPTS ON LILYPOND.ORG (16:03:11) janneke: PYTHONPATH=python python scripts/build/create-weblinks-itexi.py (16:03:28) gperciva: oh hey, that works (16:03:31) janneke: YES I BLOODY KNOW THAT - LEARN ABOUT LINUX ALREADY!!! (16:03:46) janneke: peace, love etc. (16:03:48) ***janneke is off

Post-scriptum (in a paper bag)
(by Valentin Villenave)

Actually, a few days before this IRC discussion with Jan, Graham himself had gone berserk towards your truly. That was my first instant-message discussion with him ever, and it only took him a mere five minutes to end up giving me the advice to screw something in something (can't remember the exact wording)... Nice :-)

Of course, this kind of paper-bag moments Graham was referring to above is by no means a developers' privilege. Simple users can experience it to, maybe even more so. I still have a very vivid memory of one of my most shameful moments in the LilyPond community (there were plenty, of course) : in 2006, I was just beginning to get involved in the community, it was the first time in my life that I subscribed to a mailing list (which, incidentally, is how I learned English), and I had this glorious feeling that, hey, this is where the cool kids are, with their clever remarks and witty jokes, let's become one of the cool kids, let's find something funny to say and make everybody laugh !

Needless to say, that was an utter disaster. Perhaps the most pathetic part is, this didn't even cure me from my chronic overenthusiastic hey-let's-make-everybody-laugh syndrome.

And what about you, dear readers ? Have you ever experienced such a awkward gee-what-was-I-thinking-when-I-posted-this moment ? If so, please let us know and perhaps we can laugh about it today, and therefore make you feel better ! :)

(OK. Now, where is this brown paper bag ?)

The no-we-don't-hate-Flash-videos of the Report

(by Valentin Villenave)

A few days ago, our statistics expert Francisco Vila has updated his visualization of LilyPond's source code contributions. Looking at it made me go through bewilderment, happiness and sadness ; I wonder if it will give you the same kind of mixed feelings, depending on your own past with LilyPond — and your amount of sensitivity of course :)

That was our no-we-don't-hate-Flash-videos part of the week ; for those of us who don't have Flash, here's a nice trick to use VLC instead.

News from the Frog Pond

(by Graham Percival)

The Frogs are ordinary LilyPond users who have chosen to get
involved in their favorite software's development. Fixing bugs,
implementing new features, documenting the source code : there's a
lot to be done, but most importantly : this is a chance for
everyone to learn more about LilyPond, about Free Software, about
programming… and to have fun. If you're curious about any of it,
then the word is : Join the Frogs !

In the past two months, the Frogs have begun investigating our
eventual switch to guile 2.0 (which could dramatically speed up
LilyPond), trying to make \thumb behave like fingerings instead of articulations, and trying to improve program output messages.

Honorable mention goes to our new patch-tracking worker, who has
uncovered a number of patches that I'd completely forgotten about.
It's sad to think of how much work has been lost in the hustle and
bustle of lilypond development ; I'm very happy to see a dedicated
helper tracking patches !

The Snippet of the Report

(by Valentin Villenave)

Graham was speaking of "work that has been lost" ; here's a very cool snippet that I have just saved from the darkness of forgotten, abyssal eons (namely January 2009) :

This snippet was written by Mark Polesky (now one of our most talented Frogs) to demonstrate the ability to have irregular end of staves, an irregularity that can even be emphasized with a zigzag line.

That's one enjoyable addition for my personal "hey, I had no idea Lily could do that" collection" ! :)

Granted, I was the one who was supposed to add it in the first place (January 2009 was the time where I had to officially deliver the score of my opera to the opera house, maybe that explains why I dropped the ball on this one). I'm glad that it all ended well in this case, but if you do remember of another snippet that has gone lost, please do feel free to nag me with it ! :)

Bug Report of the Report

(by Graham Percival)

Our favorite bug exchange came from a suggestion to allow 3 and 5 as durations. But what would 3 mean ?

Trevor Skeggs suggested a dotted 4. since 3 is mid-way between 2
and 4. Boris Shingarov thought that since 2 was half a whole note
and 4 was a quarter, 3 should be a third (i.e. a triplet minim /
half note). However, David Kastrup neatly resolved the
discussion :

That view is far too mathematical. 1, 2, 4, 8, 16, 32, 64 are
symbols for particular note lengths with a visible representation,
without numeric interpretation. 3, 5, 6, 7... don't have visual
representations associated with them. One of the strengths of
Lilypond is that you should be able to quote reasonably simple
input to a musician without Lilypond knowledge, and he'll be able
to figure out what you mean.

3 and its ilk don't really fit into that category. Too clever.

Three cheers for keeping LilyPond "non-clever" !

That concludes the eighteenth issue of The LilyPond Report. Next
installment is expected on July 1st, Canada Day !

Cheers,
Graham Percival & Valentin Villenave

The LilyPond Report #17

Valentin Villenave — 2010-03-01T12:22:56Z

Welcome to this seventeenth issue of the LilyPond Report!

Yay, the Report is back, with a new team! It has been said that two heads are better than one — does it apply to newsletters as well? Read on and let us know! In this issue we'll talk about websites and poetry, frogs and bugs, not to mention an extensive review of the Frescobaldi editor!
As always, you can post your comments at the bottom of the page, or even register and contribute to the LilyPond Report's next issues.[sommaire]

Editorial

At last, the Report is back! Hopefully for long, since it is now being handled by two editors, namely yours truly and... (wait for it...) Graham Percival himself!

When he's not living without the Bunnies in Glasgow, Graham `I'll be gone in a month' Percival is still on board, grumpier as ever. As a result, you can expect the new Report to have a very different tone than it used to have in the past!

Our goal is to publish this newsletter on a bi-monthly basis (that is, every two months, not twice a month). Is it reasonably achievable? Well, it depends.

If we try and keep up with the mailing lists and the LilyPond community, then two months is just ridiculously too long: that amounts to four development releases, dozens of major decisions, hundreds of bug reports, thousands of (often interesting) discussions... On the other hand, if we manage to keep our heads above the water and only mention carefully selected items, then the Report might give an interesting perspective, less directly concerned with the community's everyday life.

But most of all, as I repeatedly said for the past couple of years, the Report needs your contributions! I know I haven't been quite reliable in running it, but it's somehow a pity that the first person who finally stepped up and offered to give me a hand is also the one who's desperately been trying to leave the LilyPond project for the past three years,

Nevertheless, as Graham said:

A very grumpy Report may or may not be funny; on the other hand, maybe if there's 1 or 2 very grumpy reports, people will get motivated to write something, if only to make it more enthusiastic!

Cheers,
Valentin.

Behold our new website!

Affaire étrangère — partition d'orchestre

The new LilyPond website is nearing completion. If you haven't taken a look at it yet, try reading it now!

(Note that the translation infrastructure is not yet completed for the
new website.)

If you have any design suggestions, it's not too late to make
changes — get in touch with us.

Release news

The current stable release is 2.12.3-2; all normal users should be
engraving with this version. We have no plans on making any more
2.12 releases.

The current unstable release is 2.13.14. This version has 14
known Critical issues, with probably twice that number of
unknown critical problems. We do not recommend that normal users
engrave with it.

A common question in open-source projects is "when will the next
stable version be released?"; the typical answer is "when it's
ready". LilyPond is no exception: 2.14 will be out when the
number of Critical issues reaches 0, and stays at 0 for
two weeks. When will that happen? Well, it will happen when
these issues are resolved. Items are resolved by contributors
working on them. The more work people do, the quicker issues get
resolved.

Unfortunately, most of the current Critical issues require
attention from experienced developers; any helpful users trying to
jump in right now would only delay matters. However, issue
989 (ensure that no information is only in the regtests) could
benefit from helpful users.

What does this entail? Well, you need to look at all the lilypond
syntax inside a regression test (a short piece of testing code).
Then you need to check that this syntax is included in the
documentation. In most cases, you can just use your general
knowledge of lilypond — the docs obviously explains
cis'4., so you don't need to literally find each
portion of that syntax in the docs. However, if the regtest uses
little-known syntax or new features, the documentation might not
reflect this. We have a large number of regtests, so it would be
great if we could divide them between 5-10 people!

(Please feel free to contact Valentin if you're interested.)

— Graham.

News from the Frog Pond

The Frogs are ordinary LilyPond users who have chosen to get
involved in their favorite software's development. Fixing bugs,
implementing new features, documenting the source code: there's a
lot to be done, but most importantly: this is a chance for
everyone to learn more about LilyPond, about Free Software, about
programming... and to have fun. If you're curious about any of it,
then the word is: Join the Frogs!

Affaire étrangère — partition piano/voix

(Cette version inclut les didascalies du compositeur.)

In the past several months, most Frog activity has been concerned with guitars.

Back in 2009, our Italian contributor (and Free Software activist) Federico Bruni noted on his blog how fast LilyPond's support for tablatures was improving:

Now also the modern musician who needs tablature will be able to use LilyPond easily and enjoy the good-looking of TabStaff.
I guess this will open the doors of LilyPond to many new users.
[...]
Marc Hohl, an expert user of the LilyPond community, committed himself to creating a configuration file which allowed any tablature user to get the desired output without being forced to tweak the source file each time. Since the last spring he has submitted his changes to the users' testing and expert developers' assessment, until a great result was achieved.

I do thank a lot Marc Hohl for the great work and the patience shown in answering the questions and requests from users, who often ask for the most weird things ;-).

By the way, there is now a specific mailing list for tablature users: http://lists.lilynet.net/tablatures/

And yet, the situation has improved again since this blog post: for instance, hammeron and pulloff are now supported as well, and bends implementation is on its way, thanks to the huge amount of work provided by Marc.

Ian Hulin has also fixed an old (and quite annoying) bug about tuplet brackets.

More importantly, the Frogs have spent a lot of time discussing
LilyPond architecture, debugging techniques, improving the
Contributor's Guide, and generally laying the foundation for
future contributors. Judging from the number of posts that I
don't understand, the Frogs are definitely learning advanced parts
of LilyPond programming!

— Graham.

LilyPond's companions

Reviewing Frescobaldi
by Valentin Villenave.

For several months, I have been feeling unhappy, uncomfortable, frustrated. Then a couple of weeks ago, I finally realized what felt wrong, deeply down in my heart: I wasn't using the KDE4 desktop environment anymore! With the recent release of KDE4.4, I decided to get rid of all things GTK-ish alltogether (bye-bye LXDE, XFCE, GNOME, IceWM, Fluxbox...) and found myself with a slick, responsive, glamourous desktop environment again: then I realized what I had been missing in my life.

Feeling lighthearted again, I decided that the time had come for something I hd been meaning to do for a long time already: give Frescobaldi a proper review!

- History

Frescobaldi is a LilyPond-oriented text editor for KDE4. It has originally been intended as a plugin for the Kate editor, for KDE3 then for KDE4 when it became widely used. Frescobaldi is now developed as an independent program, albeit deeply integrated into the KDE desktop environment. It has its own website, in English and Dutch; Frescobaldi itself is well localized, and supports no less than ten languages!

- Author

Much like LilyPondTool, the other easy-LilyPond-editing environment of choice, Frescobaldi is essentially a one-man work. Wilbert Berendsen is a well-known contributor of our project, and is responsible for the Dutch LilyPond community. Wilbert is also an organist, teacher, editor, composer, conductor, performer (if I understand well, he'll be giving a concert in a few days). His website is quite interesting, and contains some scores and recordings (I particularly like this short piece by Louis Vierne in Ogg Vorbis, too bad he hasn't specified a license or I'd have embedded it here...).

- Development

Unlike LilyPondTool, where many features and graphical widgets had to be implemented (almost) from scratch, Frescobaldi uses the KDE libraries, glued together in Python using PyKDE. As a result, it has a very nice, professional look (did I mention how fond I am of KDE4 ?).

This is particularly visible when comparing, for instance, Frescobaldi:

... with the Kate editor:

As you can see, the text-editing part looks basically the same.

- Installation

From what I can tell, Frescobaldi is relatively well-known in the KDE community (with an 85% rating!); as a result it is available in most major distributions and you may not have to compile it from source (which is, by the way, not a particularly pleasant experience for any KDE app, as it requires installing hundreds of megabytes of -devel packages, plus cmake and the like).

Interestingly, the Frescobaldi packagers for my distribution (Funda Wang & Frederik Himpe) didn't specify LilyPond as a dependency, and that was a smart move: this leaves me free to download and install whatever LilyPond version I want, be it the stable, development branch, or even a home-compiled git source.

A couple of clicks is all it took for me to find myself with Frescobaldi installed, and listed in my menu under "Sound&Video" (go figure). The very last version (1.0.2) had been released just a few days ago, and yet my distribution's repository had already been updated.

- Interface

By default, Frescobaldi opens with a very minimal text area. When you're used to KDE, your first reaction will probably be to look at the vertical tabs on the left and right borders, that actually are retractable panels.

The left panel gives access to a number of articulation marks:

On the right, you may notice a "LilyPond" button. Clicking on it immediately opens two things : a terminal emulator at the bottom, and a PDF-preview panel on the right. KDE's PDF engine is used here (like in the Okular reader), whereas LilyPondTool has to rely on the (er, much perfectible) JPedal library. One minor downside though: there aren't any buttons/icons/toolbars in this PDF-preview panel, so quite a few functions are missing — plus, you better have a scrollwheel if you want to zoom it...

Unlike in jEdit/LilyPondTool, you do not have to save your source code first (and carefully give it a .ly extension). Frescobaldi is obviously meant to work "out of the box", and does indeed a great job at it: similarly, I did not have to manually specify the full path to the LilyPond binary.

At the bottom of the window, a few tabs (that I missed at first) allow you to open a terminal (just like in Dolphin,, KDE's file manager), consult the log (if any), and... record music using Rumor!

État des lieux des sujets de discussion des jeunes de 16 à 25 ans sur le Web

(Relevés bruts)

Unfortunately, I did not have the necessary tools to properly test this feature. But its interface sure looks attractive.

- Documentation

The right panel contains another tab: that's the online documentation browser. Where LilyPondTool embeds its own copy of the docs (with a very useful documentation browser that includes a search function), Frescobaldi, once again, takes advantage of the KDE libraries by embedding a web browser (the same engine as Konqueror).

This might come as a disadvantage though, as you will need an active connection to be able to browse the docs. On the plus side, this ensures that you will always have access to the latest docs build. But then again, there's still room for improvement: the browser points to the stable Documentation by default (which might be fine), but surprisingly enough, users are not offered with an option to change the URL (for example to use the latest development documentation, or an offline doc-build instead).

Another annoyance, that Frescobaldi is certainly not to blame for, is that the language detection didn't work, so foreign users may have to use the documentation and website in English by default.

Frescobaldi itself comes with its own offline handbook, like LilyPondTool (though Frescobaldi's may be a little more newbie-oriented).

- Text editing

As we've seen, Frescobaldi relies on KDE's Katepart component, and therefore has a smooth and pleasant look-and-feel when it comes to source-code editing. Blocks folding/nesting is beautifully indicated with a color gradient:

Affaire étrangère — code source LilyPond

Pour adapter la partition ou la découper différemment, vous pouvez consulter librement son code source, le télécharger, et le compiler au moyen du logiciel GNU LilyPond.
N'hésitez pas à proposer des changements, corrections, améliorations ou autres "patches" !

Unlike in LilyPondTool, not only { ... } blocks are indented, but << ... >> blocks as well:

Dossier de présentation (2006)

Context-sensitive autocompletion is well supported, which is a plus with regard to LilyPondTool: here are a few examples...

Dossier pédagogique de l'Opéra de Montpellier

Programme vendu lors des représentations

Livret de l'opéra

(version presque définitive...)

État des lieux des sujets de discussion des jeunes de 16 à 25 ans sur le Web

Commande du Conseil Général de l'Essonne, juin 2010.
© V. Villenave 2010, licence GNU FDL.

Scheme syntax-highlighting is simpler, but better-handled than in LilyPondTool (where, for instance, Scheme keywords aren't highlighted only in Scheme blocks). Still, I somehow prefer LilyPondTool's indenting and folding when it comes to Scheme code (but it's probably a matter of habit — and taste: Kate's brownish coloring of Scheme isn't very pleasant).

Like LilyPondTool, Frescobaldi features customizable code expansions:

État des lieux des sujets de discussion des jeunes de 16 à 25 ans sur le Web

(Source au format LibreOffice.)
© V. Villenave 2010, licence GNU FDL.

- Wizards

Frescobaldi includes a Score Creation Wizard, that very much resembles LilyPondTool's... but with a twist.

The first window looks exactly like LilyPondTool's... but if you look closely you'll notice that the preview "image" (that is precisely not an image, in Frescobaldi's case) is better centered... and even localized! How nice.

The usual list of instruments (aka "let's pretend we're Sibelius for a while").
Where LilyPondTool sports a three-pane interface, Fresco only uses two (with submenus), and adds specific options on the left.

Here's the twist: once you have chosen your options, you are presented with a preview of your settings! I have to confess that at this point, my jaw dropped and the only thing I could say for a while was :

woooooooow...

- Gizmos

We already mentioned the "Insertion" panel that allows to quickly add articulations to your music. This certainly looks nice, but one could argue that having to use the mouse to add articulations is hardly quicker than using the keyboard. Most users would probably prefer to assign keyboard shortcuts to these functions. LilyPondTool has also such buttons, but in a drop-down submenus, which is less convenient but preferable from a screen-real-estate point of view.

In this "quick insertion" panel, I was surprised not to find a way to quickly add slurs, phrasing slurs, or manual beams. This seems way more useful than adding \rheel or \lheel indications — but perhaps it's because the author is an organist :)

Finally, let's note that this feature is not context-sensitive. It is smart enough to leave rests alone and deal with compound durations such as cis2*5/8, but doesn't identify comments or \lyricmode blocks, nor does it take the notenames language into account.

There are a couple of nice and convenient unique tools. For instance, in the "Pitch" submenu, an option allows you to change the language used throughout your source code. Nothing extraordinary, but it's welcome nevertheless.

Another one, possibly my favorite: a well thought-out wizard allows you to easily create blank staff paper!

Impromptu pour violon et piano

Licence CC-by-sa © Valentin Villenave, 2004-2010

Once again, there's even a preview:

- Conclusion

Such features make Frescobaldi not just a nice toy to play with, but a considerate editor that has obviously been designed by someone who actually writes music. Wilbert has cleverly used all the power and flexibility of KDE4, and that amounts to a very slick software with an irresistible "wow" effect. I did have seen some screenshots on the website, I had even contributed to Frescobaldi translation, and as someone who's generally used to testing bleeding-edge software, I really wasn't expecting to be impressed. Yet here I am.

One can but regret that this beautiful software actually targets a very narrow range of users: people who run KDE4 (that's between a third and a half of all GNU/Linux users). For these users, Frescobaldi is a treat already; for example, I could perfectly imagine a classroom full of Free-Software-driven laptops running Frescobaldi. Unfortunately it's a far cry from supporting people who need such software most: that is, Microsoft Windows ~~hostages~~ users.

KDE4 is known to be theoretically portable to this system, so one could imagine building Frescobaldi for Windows. Unfortunately things are a bit complex: from QT4 that run natively without a glitch on Windows (SMPlayer), to KDE4-tied apps that require hundreds of megabytes of dependencies (Amarok), I'm afraid we're not there yet.

One last word about Frescobaldi compared to jEdit/LilyPondTool. As you may have noted, I've been familiar for a long time with this later environment. Does this review of Frescobaldi make me want to switch? Well, although I do have considered it at some point, I think I am going to stay faithful to my ugly/bloated/Java editor of choice.

Not because of the numerous features it has, which Frescobaldi does not (reverse point-and-click, real-time syntax parsing, virtual piano, MIDI player, offline docs, PDF ruler, etc.) — I have hardly ever used these features, and do not see the need for them.
Not because it's multi-platform: from now on I won't bother running anything else than KDE4 GNU/Linux. Not even because I designed its new icons :)

But more for a sentimental reason: LilyPondTool and I go way back, and I have seen its progress, I have seen Java become Free, I have seen Bertalan add new features one after another, fixing bugs, in a much less developer-friendly context than what KDE4 provides. I have taught generations of students how to install and use it, I've even made video tutorials about it.

Just like the old laptop I'm using to write this review: it's ugly, tired, I've changed almost every parts of it myself over the years. But while I can appreciate a beautiful and powerful computer whenever I see one, it's the story behind it that counts. That being said, I hope this review will give some readers the curiosity to give Frescobaldi a try, and, who knows, perhaps they'll make their own story with it — and if you do, please do tell us: we all love stories!

— Valentin.

Bug Report of the Report

Our favorite bug report from these two months came from Roman
Stawski:

 This short polyphony employs A trivial customised Voice but the lyrics ignore the first note in the score -- that's not the behaviour of choice.

As it happens, it turned out to be another instance of an existing
issue. But the creative poem was definitely appreciated!

— Graham.

... Aaand this concludes the seventeenth issue of The LilyPond Report.
The next instalment will be published on Saturday, May 2010 the 3rd.

Cheers,
Graham Percival & Valentin Villenave.

The LilyPond Report #16

Valentin Villenave — 2010-03-01T11:51:55Z

Welcome to this sixteenth issue of the LilyPond Report!

While today's instalment certainly took its time, here it is at last, with many guests and contributions that will definitely make it up. Before reading, here's a little game for you: Who said...
– "There's tons of things that I don't truly care about"?
– "LilyPond is just too flexible"?
– "Approach a computer and anything may cause a problem"?
Read on for the answers.
As always, you can post your comments at the bottom of the page, or even register and contribute to the LilyPond Report's next issues.[sommaire]

Editorial

Greetings,
why do you use LilyPond?, asked our new Release Meister Graham 'Grumpy' Percival in a recent discussion. Before the discussion went adrift (interestingly teaching us how an Elvis Presley song can be public domain), a few interesting questions were raised:
Graham:*nobody* knows *anything* about
the non-English forums for discussing lilypond? really?!?

Well, the Report begs to differ:
– LilyPond Spanish community
– LilyPond German community
– LilyPond Dutch community
– LilyPond French community
– LilyPond Portuguese/Brazilian community
– To be completed...

Why do we use LilyPond? Well, the Report has clearly enough demonstrated in the past why anybody sane enough would use it over of any other music notation software, so we believe this point has been made.
The real question would be: why do people keep hanging around even when they no longer use LilyPond? Of all the people who discuss on our mailing lists, contributors, developers, "Frogs" etc., many do not write any music: as he repeatedly said, Graham Percival himself hasn't been writing music for years; your editor has not written a single note in eight months... And yet, here we (still) are.

The way I see it, a Free Software project is not a product. It is a bunch of people, and with regards to LilyPond, a bunch of people who are both brilliant and friendly. Hence, the great high-quality software, that is merely a "byproduct" of our community.

Oh, wait. In a few weeks from now, there will be yet another compelling reason to use LilyPond: our brand new website.

And some of us are already thinking ahead. Last time we discussed the possibility of a future LilyPond 3.0 version; well, Graham — again — has begun thinking about it.

His plan? Making sure that the LilyPond syntax is one-hundred-percent consistent and safely upgradeable. This project is codenamed 'LSD', or 'GLISS', or whatever funny acronym you may come up with.

In a few weeks, you too will be able to help design what the next major LilyPond version will look like!

The LilyPond companion of the Week

After almost two years of development, the new version of the LilyPondTool plugin is finally out!

This Java-based plugin will turn any installation of the jEdit code editor, on any recent operating system, into a powerful LilyPond integrated development environnment — shorter: writing LilyPond scores has never been easier.

The LilyPond Report has proposed LilyPondTool's only developer, Bertalan Fodor, to tell us the story behind his project.

Some words about LilyPondTool

by Bertalan Fodor

It was in 2003. I just started looking at LilyPond. While I found it quite promising, its documentation was not very usable at the time, because searching was very bad, you had to have multiple many MB files open at the same time and searching all the way through to get the necessary information.
So I decided to convert the documentation to a more practical format, JavaHelp, and that was the birth of LilyPondTool.

Why Java? Because using this I can make my program available on virtually every platform. Actually I've always found strange that many free projects are telling much about "freedom as in free speech", but they mandate the OS. That's not freedom. LilyPond even at those times were an exception. They spent a lot of time providing binaries for Windows. But at that time this needed Cygwin which needed special command calls and so, so I made LilyPondTool help with this.

Then I always had problems about understanding \override, and finding out which property to set, so I implemented the \override autocomplete and so I could understand.

This happened just before my marriage in 2004. In 2005, LilyPondTool already was a quite feature rich editing tool, having many useful things at hand. But at the end of 2005, just after the birth of my first son, the most revolutionary step happened. The motivation was that, I too often made the following mistake: c.4 instead of c4. So I decided to implement an almost full LilyPond parser in Java. It was not perfect, but most errors are correctly found while typing. I think it is the most important feature of LilyPondTool.

The next big step one year later was the integrated PDF viewer and the ruler. That's again a unique feature.

Then, after the birth of my second son in 2007, I again had some time. I started to play with integrating a Scheme system in LilyPondTool, that could provide really real parsing of LilyPond input. Soon I found that you can't parse LilyPond input fully without running LilyPond fully. It is just too flexible. So I pended the project, and instead asked the community what features they'd like the most. And so this 2009 release will become the second most important release, because it contains all more complicated feature requests: the virtual piano and the dockable pdf viewer now pushes LilyPondTool to a new level of usability.

Actually my favorite feature is reverse point-and-click. It came from a feature request on LilyPondTool's SourceForge page. I think it is the feature that makes LilyPondTool really unique and fun.

What comes next? I really want to do the "almost full" parser.
– First I will change the parser engine in LilyPond to CUP instead of ANTLR, because that uses the same approach to parser generation. (LALR instead of LL(*))
– Then I will include Julie (my Guile-compatible Scheme project) in LilyPondTool. Now it will be based on Sisc. It wouldn't provide full interpretation of everything (that would need reimplementing a lot of LilyPond in Java instead of C++), but could provide quite useful features (autocompletion and instant syntax checking in Scheme code for example)

My real problem with developing LilyPondTool is that I don't have time to use it as I rarely use LilyPond. Fortunately my fellow users test my half-broken releases to polish them to perfectness...

There is one more little thing. I think it would be good to provide a download link to jEdit/LilyPondTool from the home page. Unfortunately this suggestion is still ignored, I don't know why. It's going to go only into the "alternate editors" section. But it should be an Officially Recommended Editor, and not just an alternative to the crappy editors included with LilyPond.

Many thanks to Bertalan for this contribution.

The Statistics of the Week

In the previous issue we begun looking at some statistics by Francisco Vila about the LilyPond project. In this second instalment, he provided us with two graphs:

The first one shows the evolution of the LilyPond installer size over the years. In green, Windows installers; in red, "shar" installers for Linux-x86.

I think it is funny that some sizes were crossed in 2.8 as polyphony
voices. These data are grabbed from the download page by a local PHP
script which retrieves real byte sizes from the links, not rounded Mb
sizes that appear in the web.

The overall size of LilyPond's installers has been steadily increasing. That may or may not be a good thing: it may imply that LilyPond is getting more and more powerful — and indeed, there are quite a few things you can do now in LilyPond which you couldn't several years ago —; but it could also mean that the development quality is decreasing, with less optimised code, for instance.

Of course, we're also putting a great deal of effort in making sure this will not happen. This even led our lead developer Han-Wen to complain about a possible shift in focus:

I am somewhat disappointed that a lot of the latest
lilypond efforts seem to be centered around janitorial work. While
janitorial work is often useful and a good way to introduce yourself
to a code base, it should not become the focus of either development
or discussion about development.

The mailing lists of the week

Quite interestingly, Han-Wen mentioned the way discussions about development should be handled. Indeed, there has been a tremendous amount of activity these past months, and as a result, the traffic on our mailing lists has recently impressively increased:

on the LilyPond-user list...

and even more so on the LilyPond-devel list.

While more people and more discussions might be a good thing, it also implies less intelligibility. Therefore Graham suggested that we could use some additional mailing lists, in addition to our -user, -devel and bug- list. For instance, he suggested a proposals mailing list, that could be useful to discuss long-term plans.

Well, one of the good things with having an informal community website such as LilyNet is that adding new ressources is quick and cheap, and can easily be reverted if the idea eventually doesn't work. In this regard, I started creating a few low-traffic mailing lists, designed for people who have to discuss something specific that doesn't really belong either on -user or -devel.

These new lists may now be found on lists.lilynet.net; as of today these include frogs, midi, proposals, tablatures and translations. While this initiative hasn't been officially announced anywhere, it has so far proved quite useful for some contributors, whether they want to keep informed of the translation status or improve LilyPond's support for guitare tablatures — without having to cope with the huge volume of data that's posted everyday on our main mailing lists.

The LilyPond-related-thingy-you'll-never-understand... of the week

If you have been following some discussions lately on the developer's list, you may have noticed a three-letters acronym: GUB.

The so-called Grand Unified Builder — not to be confounded with GRUB, the GRand Unified Bootloader that helps boot your operating system, was created by LilyPond's authors (Han-Wen and Jan) as a side-project. GUB, which has recently reached version 3, is...

Well, what is it actually?

Jan Nieuwenhuizen — Perhaps I can help you with that.

The LilyPond Report — Oh, hi Jan! Sure, I was getting a bit lost here. So, what is this thing called GUB and what does it do?

J. N. — GUB makes the work that the LilyPond developers do available for users: it produces LilyPond installers for all types of computers.

GUB also reduces the frequency, duration and intensity of the developer's or release manager's headaches, as it is an automated system. With a one button press, the release manager can produce up-to-date installers, straight from the latest development version, for all types of computers. So, all users are treated equal.

Having frequent releases that an ordinary, non-programmer user can use and evaluate, speeds up the feedback loop, and thus makes steering development more effective and agile.

L. R. — I understand that it is all about portability. Was it important to you that LilyPond could be installed on different operating systems?

J. N. — Ethically, yes. Han-Wen and I started LilyPond with the intention of providing beautiful and free music notation for everyone. Of course that means: users of any type of computer. Hey, I have even run it on my n770 cellphone!

L. R. — GUB was written for LilyPond only, but could it be used for other cross-platform Free software projects?

J. N. — Yes. It currently supports a minimal set of dependencies to build a few projects such as LilyPond or Denemo (about 180 dependencies/libraries are supported). It can build binary installers of your project for Windows, Linux
(also 64 bit) and MacOS X (also ppc) and FreeBSD, from the very latest sources, straight from GIT or SVN. A very light set of dependencies is required to run GUB and compile LilyPond, most everything is included in GUB [notable exceptions: perl, texlive].

It is quite dependable; the builds can be reproduced by using checksummed,
rather picky Python build scripts that bomb out on errors by default.

However, please note that:
– GUB does not provide binary packages
– GUB has a possibly fatal design flaw: it does not use a chroot to do the builds. This was intentional, it does not require ROOT, it seemed easier to access the build system. However, this means that it *cannot* produce binary packages for the native build tools.

Also, this means that in GUB there is a difference between a native linux-x86 build tool and a cross compiled linux-x86 tool, say tools::libtool and linux-x86::libtool. This is another fatal flaw, it means that a package provided by the cross build specification is not automatically available as a build tool.

– GUB is a new, standalone, mostly unsupported mini source-based distribution. It *should* have been built on .deb packages. Now, GUB users/developers have to maintain packages themselves and cannot steal/share the work from/with Debian developers. :-(

L. R. — You mentioned that GUB supported other projects, can you elaborate on that?

J. N. — As a pet project,

I added Inkscape to see if GUB would be able to handle gtk/Xorg dependent projects. I wanted to announce it, but then found Inkscape *did* provide binary linux packages. Recently I resurrected building Inkscape with GUB and wanted to
announce it to the Inscape developers, only to find
that all linux gtk+-based packages are broken. I'm still planning
to do that, but the outcome (if/when) is unknown.

In October 2007, I started working on the Novell-funded version of OpenOffice.org, Go-ooo. OO.o has always been available for windows and mac, but the current builds use the proprietary Microsoft Visual C++ environment to provide Windows binaries. So we'd like to cross build it. So far, the OOo/go-oo mingw build produces an installer, but does not run yet.

It is now being absorbed by a Google Summer of Code project and further developed in the suse build system. If that runs, and if/when I/someone finds some time, GUB could easily be fixed to produce working OO.o mingw installers, but not sure who'd use that.

L. R. — Wow, really? Inkscape and OpenOffice? Jan, you're so like a rockstar to me right now...

J. N. — Er, keep it real. Both OOo and inkscape are not used/blessed by the project and currently do not/hardly produce anything usable.

L. R. — Is it conceivable to use GUB for any software?

J. N. — Yes.

L. R. — Really? Aren't there some downsides? Hard-coded stuff, unportable requirements that may cause a problem?

J. N. — Approach a computer and anything may cause a problem :-)

(Many thanks to Jan "Rockstar" Nieuwenhuizen for his time.)

It has to be noted that, for the very first time in LilyPond history, GUB has (reportedly) been mastered by mortal human beings. As a result, the last few downloadable releases were built by Graham Percival (and others managed to get it working too.

Er, immediately afterwards it did get broken for the past three months. But do keep faith.

The Postcard of the Week

As you may have noticed, a strange disease tends to affect overly-dedicated LilyPond contributors: the main symptom of this (as of yet little known) illness is that they simply can't stay in one single country for more than a few months. For example, our Translations Meister John Mandereau has recently decided to move to Pisa, Italy — but the most affected must be our beloved contributor Graham "Grumpy" Percival, whose disease led to move from Canada to Malaysia, then back to Canada, then in a few days... to Scotland.

Fortunately, this also gave him a chance to send us a new Postcard...

Reducing Inefficiency
by Graham Percival

I stopped using lilypond 4-5 years ago. Not as part of a huge
switch to a different music typesetter — rather, I finished my
university studies in composition, and nobody was playing my
pieces. Oh, amateur musicians quite enjoyed my works, but I
wasn't finding any interest from the academic community. So I
moved on to other fields, eventually ending up in the emerging
field of computer-assisted music education.

So why am I still doing lilypond development? Well, there's a
number of reasons. Fondness for open source, personal
friendships, adding material to my CV... but the biggest reason is
my distaste for inefficiency.

My first steps in LilyPond development were directly fueled by
this: I saw people asking the same questions over and over. They
were answered politely (it generally wasn't me answering them :),
but this struck me as inefficient. Answering an email might take
5-10 minutes while improving the documentation could take 30-60
minutes... but by the time you had answered 6 emails, it would
have been better to improve the documentation.

However, improving the documentation wasn't trivial: it took me
two weeks to figure out how to begin fixing typos. I had to learn
CVS, configure, install a ton of dependencies, diff, etc. They
were all tools that served me well in later years, but they were a
fairly large barrier to contributing. It didn't help that I was
very shy about asking for help.

When I decided to stop doing documentation work, I still
remembered the initial discouragement, so I started the Grand
Documentation Project. The stated goals were to clean up a large
portion of the documentation, but the unofficial goal was to train
a group of people to replace me. In the beginning, I would take
care of all the technical details (source management, diffs,
making sure the texinfo files compiled, etc), and if they seemed
serious about long-term documentation contributions, I would
gradually wean them off my assistance.

Later on, I noticed that potential programmers couldn't figure out
how to get started, and the existing programmers had learned that
many well-intentioned offers of programing never pan out when they
have to actually do work. As a result, existing programmers
didn't spend much time discussing potential programmers. In most
cases, this saved the community time, but I'm sure that some of
those potential programmers _would_ have been great contributors
if they had been mentored. I therefore started the Contributor's
Guide, as a combination of help and warning to anybody thinking
about getting involved. If they were serious, they could read how
to get started. If they weren't serious, they would get
discouraged before anybody invested time mentoring them.

I'm fond of the phrase "in a democracy, we receive the government
we deserve" (the quotation has been ascribed to a number of
people). I like to apply it to lilypond: "in an open-source
project, the community receives the program / bugs / documentation
that they deserve". If a user truly wants something done —
explaining something better in the docs, fixing a bug, making a
flashier website — then they can help do it.

Of course, what if they want a bug fixed, but don't know how to
program? I have three answers.

First, in keeping with my theme of altering political phrases, I
employ the term "trickle-up development" (coming from
"trickle-down economics). The idea is this: even if you don't
know anything about programming, you can help doing other tasks.
This means that the other developers don't need to do these tasks
themselves, which means they have more time to spend on the tasks
which you can't do.

For example, my next task after sending this email is to handle a
complaint that our direction-specific documentation isn't clear.
One user had difficulty figuring out that \slurUp affected all
future slurs, while ^( affected just one slur. So I need to read
NR 1.3.2 Slurs and NR 5.4.2 Direction and placement, figure out
how it could be explained better, and write the text and/or
lilypond examples.

This isn't hard — I'm willing to bet that almost all readers of
the Report are capable of explaining the difference. And at least
21 people are capable of modifying the docs accordingly, because
that's how many people contributed to GDP. But nobody else
investigated this "mundane, routine" issue, so I'm going to do it.
After that, I'm going to investigate/document/fix some problems in
the release process — I'd like to make a new 2.12 release that
has a working GUI for OSX 10.5. If somebody else had done the
documentation issue, I wouldn't need to do it, so I would be
working on that problem now. The connection between user
documentation and better releases might not be obvious, but it's
there!

The second way that users can fix bugs when they don't know how to
program is simple: learn how to program. Don't claim that you
can't learn anything — if you're alive, you can learn. If you
truly care about some issue, then you'll spend the time to learn
how to fix it.

I'm not blaming you if you *don't* truly care about beamlets,
Gregorian notation, or whatever the bug is. There's tons of
things that I don't truly care about! But I don't claim that such
bugfixes or new features are truly important to me.

The third way is a combination of the above two points: take care
tasks so that other developers don't need to do them, but always
keep trying to do tasks that are slightly more complicated than
you can currently handle. Learn how scheme tweaks work by writing
documentation about scheme! Improve your knowledge of lilypond
fundamentals by editing the tutorial for beginners! Increase your
scheme proficiency by creating a neat tweak, then try fixing a bug
that uses the same kinds of scheme constructs!

Of course, this third way is slightly dangerous: as you work on
more complicated things, you'll want to stop working on the
simpler things. But if those simple things are "daily
maintenance" tasks, then somebody's gotta do them. So either you
get stuck doing mundane tasks, or you recruit new contributor(s)
to do those easy tasks, allowing you to concentrate on more
complicated issues.

Say... anybody want to learn how to write documentation for
lilypond?

... Aaand this concludes the sixteenth issue of The LilyPond Report.

Cheers,
Valentin Villenave

The LilyPond Report #15

Valentin Villenave — 2010-03-01T11:50:02Z

Welcome to this fifteenth issue of the LilyPond Report!

Where do you go when you're looking for LilyPond scores? Are we soon going to see a LilyPond 3.x series? How _not_ to print music with LilyPond? And why use the Internet to turn on a lamp? These are some of the questions that will be addressed in today's issue of the Report.
As always, you can post your comments at the bottom of the page, or even register and contribute to the LilyPond Report's next issues.[sommaire]

Editorial

Greetings,
at last, a new Report; as you may have noticed, I am currently (unfortunately) unable to publish this column on a weekly (if at all regular) basis, so it's more of a Debian-like "release-when-ready" style. As I said many times, my main problem as an editor is not to find something worth writing about, but about making choices in the never-decreasing number of interesting things that happen every day, every week, within our community and in the Free Software world.

But even when you've decided to deal with a specific topic, finding a proper way to do so is hardly the easy part. Sometimes the material is there, for instance on the mailing lists archives, and it is just a matter of patience to find it. Sometimes there isn't enough material, and you have to investigate a little bit. And sometimes, well, sometimes the hardest part is to put things together with some sort of a logical sense. This week's article about LilyPond scores wasn't a easy one to write in this regard.

In the former instalment, we talked about the new Frogs team; well they now have a dedicated homepage on LilyNet, where you can read (and subscribe to) their mailing list. Please also have a look at their place on the Wiki, which Patrick McCarty has been busy setting up. On the upcoming issues, we will have a closer look at this team and what they do.

Eventually, Francisco Vila has begun to provide the Report with interesting statistics about the LilyPond project; we'll have a look at that today and in several issues to come.

What's up with LilyPond (-scores)?

Recently, Wilbert Berendsen shared with us a score he has just engraved, introducing the source code repository he has created for the occasion at Google Code.

The .ly files live in the lilymusic googlecode repository, a repo which
I'm btw happy to share with anybody wanting to write good LilyPond scores (of public domain or otherwise Free music) under free licenes and svn version control.

This led Jay Anderson to make a short list of known LilyPond scores source-code repositories:

– Wilbert's

– A lesser known Google Code project, from a Spanish-speaking contributor whom I do not know,
– Jay's own repo,
– Sven Axelsson's repo (mostly bagpipe music),
– Xavier Shay's repository (a few jazz scores),
– your editor's work,
– last but not least, Master Nicolas Sceaux's repository of authoritative editions of baroque music.

Of course, such repositories are meant to host only source code. But a number of free online music libraries include LilyPond scores. On these websites, you can download scores as compiled PDF files, as well as the sources.

– the Mutopia project immediately comes to mind. It contains only LilyPond-engraved scores, all released under specific Free licences.

– the International Music Scores Library Project (IMSLP) has been going through a lot, but is now back online. Is contains mostly scanned scores, but you may find some LilyPond scores. And these may include source files.

– the Werner Icking Music Archive (WIMA) has many PDF downloadable scores. Some of these have been engraved using LilyPond. Some may come with their source files.

–

the Gutenberg project now has its own music library. Whether it will contain many LilyPond scores or not remains to be seen.

– the Choral Public Domain Library (CPDL), as its name states, is about vocal music. Even though it is not limited to LilyPond scores, several members of our community do contribute to this library on a regular basis, including Andrew Hawryluk, Peter Chubb, Reinhold Kainhofer or Laura Conrad. Laura has contributed 133 scores as of this day, and she explained why she'd rather post these scores on CPDL than on Mutopia:

for a particular piece of music, I think it makes more sense to
either have it on my own website or to contribute it to a more central
place where people are looking for music.
In other words, I don't expect people to look for a madrigal typeset in
lilypond; I expect them to look for a three-part madrigal, or a madrigal
by Thomas Weelkes, and mutopia doesn't particularly have a reputation in
the madrigal-performing community as a place to go (unlike Werner
Icking or CPDL).

Of course, many LilyPonders do publish their scores on their personal websites, and it would be absolutely impossible to reference these here (if at all). It allows them (like Nicolas Sceaux) to offer their scores either as compiled PDF or source archives.

Source code repositories, online music libraries, and personal websites: quite a lot of resources to look at, and one can wonder if things couldn't be made simpler. In different ways.

– The one website to rule them all approach. According to Hajo Dezelski (and he certainly has a point), this website should be Mutopia:

I ask myself again why do I have
to add another link to my list, when we have a working repository for
music: Mutopia.

Following closely discussions on this mailing-list you will notice
that tons of scores are engraved with Lilypond. (Applause!) And most
of this music seems to be without any copyright restrictions. But I
can seldom find them in Mutopia.[...] Why is Mutopia not the official music code repository for Lilypond?

The upside: well, one single place, wouldn't that be nice...
The downsides:

- What do we do with already existing external resources?
- How do we handle syntax evolution?
- What about licensing constraints?

– The let's make something new and better approach. For instance, Mike Blackstock is aiming to open a new Wiki, that (unlike our current Wiki) would be interfaced with LilyPond and designed to host scores.

The upside: wiki-like editable scores! How cool is that?
The downsides:

- On the server side, it requires some serious computing power.
- On the implementation side, it requires a crew of skilled web-developers.
- Whether a wiki-interfaced LilyPond can deal with complex source code (with includes, lots of Scheme, etc) in a safe way has yet to be proven.

– The geeky web 2.5.0 shiny venture capital newfangled interactive web my-face-space-book stuff approach (Graham K. Percival). I said earlier that referencing all personal websites/repositories/music libraries that contain LilyPond scores is a nearly impossible task. However, there may be a way to achieve it: by offering a central, widely-visible place where the LilyPond community can unite their strengths. For example, the IMSLP has an impressive list of free online music libraries.

There's more to it. Through a customized Google search box, through RSS feeds aggregation, JavaScript embedding etc, we could conceive a simple webpage where people could, at a glance, see the latest Mutopia/CPDL additions, as well as a preview of Nicolas Sceaux's latest score (yeah, that's three times I mention him, what do you know, I'm a big fan), search for a specific score in all LilyPond resources known to man, and so on.

In a similar way, I can imagine a source code repository that would be interfaced with both SVN and GIT, and that would automatically retrieve the source code from given external repositories.

The point with this latter way would be to leave resources were they are, but to reference, syndicate them, and therefore give them visibility, consistency, and ease of use.

News from the Free world (and Lily)

So, more than two years after the last stable version, LilyPond 2.12 was released on Christmas Eve. While we had been looking forward to this for months, it still came as a surprise — which some of us weren't happy about, because of unresolved bugs or documentation issues.

Such controversies aren't unusual in the Free world; one can think, for

instance, about the KDE 4 quarrel. Moreover, Reinhold Kainhofer made an interesting point:

As things are currently in LilyPond, I don't think that the term "stable
version" makes much sense. All our releases seem to me like snapshots of the
current development version at some random times

This, in turn, brings up the question of the version numbering model.

For ages, LilyPond used the same numbering model as the Linux kernel: odd-numbered development releases, even-numbered stable releases. This model has one big downside, that we just experienced: it tends to make the development cycle really long, and at some point the 'stable vs unstable' question becomes irrelevant.

Projet Pinocchio - La partition

Cette partition a été compilée sous forme de fichier PDF, prêt à être imprimé et déchiffré !

Projet Pinocchio - La partition

Cette partition a été compilée sous forme de fichier PDF, prêt à être imprimé et déchiffré !

Therefore, the Linux kernel has dropped this model, just issuing one release after another, exactly in the same way that Reinhold suggested. Recently, Linus Torvalds even considered entirely dropping the 2.6.xx.x naming model, since nothing compelled him anymore to switch from 2.6 to 2.8, or even from 2.* to 3.*...

While it is unlikely that we'll see a Linux 3.0 version any decade soon, LWN's Grumpy Editor has predicted that the 2.6.* numbering scheme will still go on, and make it at least to 2.6.33 by next year.

And what about Lily?

Well, it seems that, after all, we're not far away from the Linux situation. Like the Linux kernel, LilyPond has moved from a small 0.x project to a bigger community-driven 1.x project with more developers; then some major internal changes (particularly introducing the Guile interpreter) have led to a new 2.x series... And now?

In August 2004, Han-Wen announced:

LilyPond development is gearing up towards a new, better, funkier
glitzier stable release, and that is LilyPond 3.0.

In February, he was still referring to LilyPond 3.0. A few months later [1], it became 2.10 instead. And then, 2.12, 2.14, etc...

So, are we stuck in 2.* numbers? I'm not sure. I think it's a matter of generation. LilyPond started approximatively at the same time as other GNU parts, such as Glib/GTK or the Gimp, that are still at version 2.* as well. One could also mention the Blender project [2], that it now at... version 2.49!

Not only does that mean that LilyPond is as active as other successful free software projects, but it also implies that, even as a "niche" project, we're still part of something bigger. And this "bigger picture" is moving forward: fohttp://news.lilynet.net/ecrire/?exec=articles_edit&id_article=109r instance, the

GNU project's General Public License has reached version 3 less than two years ago; it has also recently been decided that GNOME 2.30 will be renamed GNOME 3.0. [3]

Anyway, as Linus Torvalds once said (at a time where the Linux kernel 2.6 was thought to become 3.0): "Hey, it's just a name"...

The Statistics of the Week

Our Spanish contributor Francisco Vila has been busy lately, and he came up with some statistics (and some comments) about the LilyPond project. This week, we'll present the first part of his observations.

I was curious about the health of the LilyPond documentation
and I have made this graph.

Though most people browse it online or as a PDF file, LilyPond's documentation is also downloadable as a `tarball' archive on our website. This graph shows the evolution of this archive's size, over the years.

As you may know, "There are three kinds of lies: lies, damned lies and statistics" (Mark Twain). Nevertheless, what can we notice? In two years, the doc size has been multiplied by 4; this may have something to do with translations (that were basically not there in version 2.8). But the main cause is obviously the Grand Documentation Project that has been led by Graham Percival over the whole last year. On this subject, Graham commented the way these statistics were made:

if you *really* want to see a spike for GDP, let's look at
the size of patches in git. Or even better, look at the
percentage of patches which are documentation-related (i.e. modify
Documentation/ or input/ ) as opposed to code-related. ;)

However, I think the overall shape looks good... and promising for our future. Francisco, on his side, has gathered a different comment:

My two daughters said immediately that the drawing was "a
little path of stars". Isn't it lovely?

It certainly is :)

The Idea of the Week

To me, the "We Can" phrase is much less of a president's motto than a geek-defining mantra. You may know this geek-oriented US TV show called The Big Bang Theory; if not you can have a look at the first two minutes of this clip and pay attention to this line (slightly rephrased below), which I believe defines the very essence of geekness:

— Why do you send a signal from this laptop, through your local ISP, racing down fiber optic cabel at the speed of light to San Francisco, bouncing off a satellite in GS synchronous orbit to Lisbon, Portugal where the data packet will be handed off to submerge transatlantic cabels terminating in Halifax, Nova Scotia and transferred across the continent via microwave released back to your ISP and X10... to turn on a lamp???

— Because I can!

Anyway, from the just because we can collection...

This week's idea was posted by our Ukrainian contributor Dmytro Redchuk on the mailing list:

I thought of \repeat unfold in a context of some experiments
with "concatenateable" fragments of music, lyrics etc —
can not say now with what exactly;
so i can not tell whether i need this or not :-)

Of course, you must already be familiar with the widely-used \repeat unfold n {...} command, that prints the music expression n times. But... have you ever thought of using it not to print music?

\repeat "unfold" 0 { d4 d d d } % "zero" here
To be honest, i would expect this bar not to be engraved.

This "feature" is currently not available in LilyPond. Maybe someone will implement it some day... "What for", you might ask? Well, because we can! :)

LilyPond's companion projects

This week's "project" is more of an experiment, that could remind you of the special issue we had previously published about algorithmic composition.

On January the 5th, one of our French LilyPonders, Martial, inadvertently posted a mail on the -user list, announcing (in French) a new version of POV-ray (another Free Software project he seems to be involved in).

The Persistence of Vision Raytracer (aka POV-Ray) is a major project of the Free World (it has been developped for more than twenty years), that allows to render high-quality computed-generated 3D images. Similarly to LilyPond, its input format is plain code (it can, however, be interfaced with graphical modeling programs such as Blender). Its development seemed to have been slowing down for the past five years, but Martial's announcement of a new version proved that it's still well alive and promising.

This little mishap led to an interesting discussion, where Cameron Horsburgh believed that LilyPond had precisely been (remotely) inspired by the POV-ray language... But the coolest part is probably when Martial modestly took this as an opportunity to show us his work with computer-generated animations and LilyPond scores

Here are some explanations, translated from his website:

Some Python, some Pov and a lot of LilyPond:

the score (notes and rhythm) is randomly generated by some macros, randomly selected out of a prepared "pot", and then saved as a LilyPond file.

The image is generated from the same "pot": a macro somehow rotates a globul-blobtuberence field.

A random factor is seeded by a Python script involvind the system clock; then the score is engraved by LilyPond from the output file. Here's the source POV file that produced this LilyPond example.

Through the Python Imaging Library, the image is converted into EPS to be handled by LilyPond; the MIDI output is converted into mp3 through TiMidiTy.

[...] Instruments are arbitrarily chosen at the beginning of the POV source file.
Example:
#declare Instrument_1= "\"trumpet\"" or
#declare Instrument_1= "\"harpsichord\""

How cool's that? If you're geeky enough and want to experiment making 3D LilyPond scores "just because you can", then you'll definitely want to have a look at Martial's source code. Feel free to send us your creations, as the Report will happily feature them in its next issues!

The LilyPonder of the Week

Some day in March, your editor had the pleasant surprise to meet someone special on our -user list. I am, of course, referring to

Miklos Vajna, a Hungarian young developer whom we owe one of my favorite GNU/Linux distributions [4]: Frugalware.

What better way to introduce this distribution than by quoting this Distrowatch paper from 2006, which I believe is still dead on:

Frugalware Linux is one of those distributions that does not feature often in the news headlines. But those users who take the time give it more than just a passing glance are often surprised to find in Frugalware a clean, fast distribution with a great package manager and a few convenient system administration tools. Loosely modelled on Slackware and incorporating Arch's 'pacman' for managing installed applications, Frugalware Linux is not only a great operating system, it is also an active community project based on open source ideals.

As I said back then, Miklos is to Frugalware what our own "benevolent dictators" Han-Wen and Jan are to the LilyPond project; that should give you an idea of the amount of respect he deserves. So, what brings Miklos in the LilyPond community? Here's what he told the Report:

I play guitar for about 13 years, not that I'm that good in it, but with
time I tend to learn a bit. In the past five years most of the time I
played religious songs and that has nothing to do with LilyPond, it's
just a textbook with guitar chords. But from time to time I occasionally
play other old songs like Steve Wonder, The Beatles and such. I buy or
download the music sheet, print it out, then usually change it a bit,
since the original chords are for multiple guitars / instruments, etc.
When I'm happy with the shape and I'm tired of programming, occasionally
I try to let LilyPond create the music sheet for my version of the song.

What I like in LilyPond is of course its programming language-like
interface, which is quite comfortable for a programmer like me. I used
Finale once about 12 years ago and it was boring, I hate to use my mouse
too much. :) Also the community is wonderful, every time I ask something
on the list I get helpful answers. Not to mention the documentation,
IIRC the notation reference is 500+ pages. As a result usually my
question is not "Is it possible?" but "How to do it?". ;)

BTW, I first noticed LilyPond because I knew Han-Wen Nienhuys because of
his darcs2git and Jan Nieuwenhuizen because of ooo-build (I contibuted a
few patches to both projects), so it was something I had to try out as I
was sure it'll be quality software. :)

If you want to learn more about Miklos, you can have a look at this recent interview in the Frugalware Report — sorry, Newsletter.

The quote of the week

Upon special request from Graham Percival, this week's quote was found in a long discussion involving (yet another) Grahamized newbie named Tim Rowe:

The lilypond documentation really isn't the kind of documentation that you can go to when you want to know how to do something. It's designed to teach you how to use the software.

Comments are opened below.
[5]

... Aaand this concludes the fifteenth issue of The LilyPond Report.

Cheers,
Valentin Villenave

[1] I remember this was explained in a mail on -user (by Mats?), but I couldn't find it. Anyway, in a long (annoying) conversation in July 2006, Erik Sandberg used the 3.0 numbering, then a few days later the 2.10 numbering. My guess is that this is when the change took place.

[2] By the way, the third Open Movie project (codenamed Durian has just been announced, and it looks really exciting.

[3] ... And there I have managed to put both KDE and GNOME logos. Hopefully no flamewar today.

[4] Was my top #1 actually. And then KDE4 came out.

[5] In fact, I am not sure that I understand it completely, since I have been learning LilyPond the other way around: at first I only wrote very simple scores, and while reading the documentation my scores became more and more complex since everytime I found a new feature I just had to find a way to use it: "Hey, let's put a Voice-Following line somewhere! Hey, where could I use feathered beams in this piece? OK, let's add another measure for that..."
... And before you ask: yes, the "because I can" approach is the wrong way of composing music. But what do you know, I'm just a geek.

The LilyPond Report #14

Valentin Villenave — 2010-03-01T11:38:41Z

Welcome to this fourteenth issue of the LilyPond Report!

[...]
As always, you can post your comments at the bottom of the page, or even register and contribute to the LilyPond Report's next issues.[sommaire]

This Week's Desultory Editorial

Greetings,
[...]

News from the Free World

[OLPC situation]

What's up with LilyPond?

[Lily for childrens: testimony]

The LilyPond Feature of the Week

[...]

LilyPond's Companion projects

[DIY Keyboard project, article from Andrew Wagner]

The Idea of the Week

[...]

The Snippet of the Week

[Gilles' last snippet?]

The Bug of the Week

[sub-beaming broken]

The Interview of the Week

The LilyPond Report — Hello Reinhold, thanks for answering our questions today!

Reinhold Kainhofer — Likewise, nice to have a chat with you!

L.R. — Introducing you to our readers is not particularly easy, since you've been actively working on many various things within the LilyPond community... For instance, last week we've seen that you've just implemented native support for complex tempo indications (mixing text and metronome marks).

Reinhold — You are right, I am quite active, and not only for LilyPond. However, the things I have done in the last few days were not so much work, but simply got a lot of attention. Hmm, let me think; MusicXML import (musicxml2ly) was actually the first stuff that I worked on, in August 2007...

L.R. — Yes, the LilyPond Report has introduced this feature a couple weeks ago (has you once noticed, your name gets frequently mentioned in this column)...

Reinhold — I have also been contributing to the LilyPond Snippet Repository, of course, where I submitted 21 snippets so far. With John Mandereau, I've been investigating possible design improvements for the LilyPond website and online documentation; and I'm also a contributor or the Choral Public Domain Library.

L.R. — Indeed; by looking at the list of your scores, I understand you're involved in a choir?

Reinhold — Yes, I initially simply started using LilyPond to write scores for our choir (after having used abc2ps)... But then, some questions on the user mailing list intrigued me, in particular that strange incomprehensible language called Scheme... LilyPond is addictive, but it's also very complex; to be honest, I still have no real clue about the inner workings of LilyPond: when I try to implement something, I mainly take some existing code and try to adjust it to my situation (mainly by trial-and-error).

L.R. — This meets what I wrote last week: there's no real border between working with LilyPond and working on LilyPond...

Reinhold — Yes, invariably, you'll run into something that you need and that LilyPond does not do yet.

L.R. — ... Or you end up constantly pushing Lily, looking for anything that it cannot do yet!

Reinhold — Yes and no. As I said, I started by writing scores for our choir, then we had a performance of Schubert's Stabat Mater, for which no orchestra material was available for sale (only for rent...). Thus, I decided to get an old (out-of-copyright) edition and write the orchestral parts with LilyPond. That's also how I got into the territory of orchestral scores; and that's one area where you are constantly pushing the edges of what LilyPond can do and what it can't.

L.R. — ... Which led you to conceive your OrchestralLily package.

Reinhold — Yes, that mainly evolved from my orchestral scores, where I realized that for each instrument / group and for each movement I had to do the same definitions over and over again. And then I ran into other problems, so I put the solutions into that package too. Oh, this makes me think I should finalize version 0.03, which adds lots of new stuff over version 0.02. Docs are at http://kainhofer.com/orchestrallily/, and the latest version can be downloaded at http://repo.or.cz/w/orchestrallily.git.

L.R. — Er, this should have been my line actually... So, you're a singer?

Reinhold — Yes (mainly bass, but I can also sing baritone). I'm actually singing in 2-3 choirs: the choir of the St. Augustin church in Vienna (which is the church of the former emperor's palace in Vienna and where Sissy got married), where we have a choir mass (with a large orchestra) every Sunday; also the Chorvereinigung "Jung-Wien", which is mainly specialized on classical Viennese Waltzes, Polkas, etc; but we also do other concerts like the Stabat Mater, or a musical concert this fall.

L.R. — These choirs must be huge, if they can afford such large performances...

Reinhold — The first one is mainly funded by the parish, but the second one needs to finance itself: by getting subsidies from the city (which is quite hard this year, since all the money goes to the soccer championship), but also charging for the concerts — being in Vienna is especially hard for musicians, because there is so much competition here.

L.R. — Judging by the (impressive) résumé on your website, you are specialized in many different areas: mathematics, physics, economics... Is it because it "just happened", or are you genuinely interested in tons of things?

Reinhold — Yes, that's one of my problems: I take on so many things that I hardly have enough time. I'm interested in everything, so it happened automatically. For example, I studied Mathematics and physics, now I also took up some law studies, I'm taking solo singing lessons, try to improve LilyPond, and — because I might get bored during the weekends ;-) —

I'm also a referee for American Football.

L.R. — Oh, not to forget that you have a "normal" day job at the university of Vienna.

Reinhold — ... Which is apparently not too stressy, since I find the time to talk with you during my work hours ;-)

L.R. — And what about computers? Did you start programming because of your studies... or are you just another computer geek?

Reinhold — I'm simply a computer geek for no particular reason. I never studied programming or took courses, I simply learned it myself. I started programming Windows applications using Borland Pascal and Visual Basic, when I was in high school (I was in boarding school, so I was allowed to use the school's computer root!). Then at university I got in touch with Mathematica and in 1999 I worked for Wolfam Reseach (first as a summer intern and then as a contractor), the creators of Mathematica.

L.R. — Interesting! Is Mathematica still one of your favorite languages? I remember that a few months ago Trevor Bača told us he had been using it to process music; have you ever tried to do so?

Reinhold — To be honest: I know that Mathematica can process music and I suspect that it can be quite efficient and easy, but I never looked at it. My favorite programming language depends on the problem. Either C++ (for writing efficient numerical applications), Mathematica (if I need to calculate something symbolically), Python/Perl for simple scripts, etc. Scheme (and the C++ that LilyPond is written in, which is basically just Scheme written in C++ Syntax) is definitely not one of my favorites ;-)

L.R. — So, long story short, you ended up becoming a Free Software user and developer...

Reinhold — During high school I got in touch with computers and started programming, but that was only for Windows. My first contacts with Linux were at the time I did the summer internship at Wolfram Research, as one of my roommates there was very fascinated by it. The irony: when I met him a few years ago, I was the Linux developer, while he had meanwhile switched to a Mac... I'm using Linux on my office machine (running Debian sid) as well as on my laptop (running kubuntu hardy) and my wireless router (running OpenWRT). I've been quite involved in the KDE project for several years, where I also was the maintainer / lead developer of KOrganizer. I simply lack the time and also the motivation to work on it any more; now I'm "only" a happy KDE user (and seeing what Wilbert did with lilykde is really a great please, since it shows how great that desktop can be).

L.R. — You seem to care about software freedom; has it something to do with the fact that you're a scientist, and specifically a scientist involved in _public_ research?

Reinhold — Coming from science, for me it is absolutely natural that the things I do can be used and are useful to others. That's basically the idea of open source. I'm not after the money (otherwise I wouldn't be at university, but probably in some investment bank), but I want to do something that I like and that helps others, too. As for public vs private research, I think that's basically a matter of philosophy. If you are in a private company, things tend to be closed, results are not shared with "competitors", etc.; it's basically only about money and competitive advantages, but not about the people involved or the society as a whole. I don't know if people who like working there are not so interested in sharing their (sparetime) work with others in principle or if they get so used to these ideas as time passes.

L.R. — Yes; I couldn't help noticing that most, if not all, scientists I've met through LilyPond (Trevor Daniels, Torsten Anders, Peter Chubb and many others) were involved in public, government-funded facilities and/or universities. Now I won't jump to conclusions, since sometimes you don't really get to choose and life chooses for you... Let's talk music again. You do not seem to be into contemporary music at all, are you?

Reinhold — No, I'm mainly into classical choir music. I like contemporary music and listen to it, of course, but mostly I simply find it too shallow.

L.R. — Yet, given your background as a mathematician, you might be interested in Algorithmic Composition such as what Torsten Anders or Trevor Bača do...

Reinhold — Hehe, that's definitely an interesting area. To be honest, I'm currently thinking about switching my areas from financial and actuarial mathematics to computer science, in particular music information retrieval.

L.R. — Wow! Can you really do that? Wouldn't you lose your job or something?

Reinhold — Of course, I would have to give up my position as an assistant professor, but I already talked to one of the CS profs and I might get a position in a EU-funded research project (if that gets granted). The exact field, of course, depends on which project will be granted (in the next few weeks), but there are so many interesting issues in information retrieval...

L.R. — You seem to really have given it a thought indeed.

Reinhold — I would probably do this, because I realize more and more that financial mathematics is not what really interests me (economics was never so interesting, not the least because it's all about money, which has very low priority to me). Also, Mathematics is interesting, but then it always tries to be as abstract as possible, so I'm missing the real applications.

L.R. — Well, good luck for your plans, and for your future work with LilyPond; can you imagine yourself becoming a regular contributor/developer in a distant future?

Reinhold — Yes, absolutely. I'm quite motivated about LilyPond, although I'm seeing that it takes way too much of my time. Sometimes I'd rather write scores in LilyPond than fixing bugs that prevent me from writing the scores.

L.R. — Well, it's an addiction, as you noted... Thanks Reinhold; see you soon on the lists!

Reinhold — Thank you for the talk, too.

Thanks to Reinhold Kainhofer for this interview.

The Quote of the Week

[...]

And this concludes the fourteenth issue of The LilyPond Report.

Cheers,
Valentin Villenave

Tutoriel n°7 pour LilyPond

Valentin Villenave — 2009-11-13T16:21:24Z

Bonjour à tous et toutes,

Aujourd'hui je vous propose de découvrir le rythme et toutes ses subtilités dans LilyPond !

Retrouvez cette vidéo dans d'autres formats sur cette page.

À bientôt pour la suite de nos aventures !

Valentin

Tutoriel n°6 pour LilyPond

Valentin Villenave — 2009-11-06T14:09:22Z

Bonjour tout le monde,

aujourd'hui un tutoriel un peu plus court, pour expliquer le plus clairement possible l'usage des variables et leurs nombreux avantages.

Retrouvez cette vidéo dans d'autres formats sur cette page.

À bientôt pour d'autres épisodes !

Valentin.

Tutoriel n°5 pour LilyPond

Valentin Villenave — 2009-11-05T13:44:25Z

Et de cinq ! Cette fois nous mettrons vraiment les mains dans le cambouis, avec des morceaux de Rameau et de ligne de commande dedans.

Retrouvez cette vidéo dans d'autres formats sur cette page.

Quelques liens que j'évoque dans le tutoriel :
– L'archive Werner Icking
– L'International Music Score Library Project
– Le Projet Mutopia
– Wikimedia Commons

Bon courage, et à bientôt pour de nouvelles aventures !

Valentin.

Tutoriel n°4 pour LilyPond

Valentin Villenave — 2009-11-05T00:39:08Z

Bonjour tout le monde,

Cette fois c'est du sérieux ! Je vous propose de copier, pas à pas, un fragment d'une oeuvre du grand répertoire ; vous constaterez par vous-même que Lilypond n'a rien à envier aux partitions des grands éditeurs.

Retrouvez cette vidéo dans d'autres formats sur cette page.

À bientôt pour la suite !

Valentin

Tutoriel n°3 pour LilyPond

Valentin Villenave — 2009-11-04T22:05:56Z

Bonjour à tous et à toutes,

voici un nouvel épisode de ma série de tutoriels vidéo pour LilyPond.

Aujourd'hui on s'attaque à un sujet plus excitant, puisque je vous propose de recopier avec moi la Free Software Song de Richard M. Stallman !

Retrouvez cette vidéo dans d'autres formats sur cette page.

À (très) bientôt pour la suite !

Valentin