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.
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.
- John Mandereau and Valentin Villenave, aka The French Geek Team
- John took this picture with his cell phone a couple days ago, outside the Beaubourg Museum in Paris. We also met with Spanish LilyPonder Francisco Vila and his family — but forgot to take a picture
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.
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!
- LilyPond’s installer for Windows is built using GUB
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…
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
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
