The LilyPond Report #13
Tuesday 24 June 2008 by Valentin Villenave
This short, informal weekly opinion column is about the GNU LilyPond project: its team, its world, its community. It is not meant to be an exhaustive documentation resource. Reader comments are, of course, welcome (see at the bottom of this page).
Welcome to this thirteenth issue of the LilyPond Report!
This week we’ll talk a bit more about how Free Software, and particularly LilyPond, is developed, evolves, and ends up having a life of its own. We’ll also talk 3D gaming, spectacular visualizations, but also visual impairments and music robots. 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.
This Week’s Desultory Editorial
Greetings,
I never get tired of saying that every week: Free Software is an amazing thing. For instance, using LilyPond doesn’t makes us just "users", but actors as well; the limit between working with LilyPond and working on LilyPond is extremely thin, anyone of us can experience it. Therefore I never refer to LilyPond as product but a project.
You could think that this is just politics; well, to me it is, but in a good way. I remember an article by Richard Stallman where he referred to "computer-using citizens"; well, I do believe that being part of Free software, Free culture, Free knowledge projects defines us as citizens. A new kind of citizens: citizens of the Free World.
This week I discovered something amazing, that you really need to see. A few weeks ago, José Padovani told us about the Processing visualization programming language [1]; Michael Ogawa, a student at the University of California-Davis, has found an incredible way to use it.
Based on the history log of several famous Free projects, he’s been able to build an organic visualization of their development by the community.
I’ve been studying software projects for a while now. Not the programming, but the people — the way they interact with each other through collaboration and communication. [...]
This visualization, called code_swarm, shows the history of commits in a software project. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away.
Here is, for instance, how the Python scripting language has been developped for the past fifteen years:
It’s alive!!!
News from the Free World
Last week’s Firefox 3 Download Day has been an overwhelming success; more than 8 millions downloads in 24 hours, about 18 millions in a week... Our special correspondent (namely myself) has been following the event very closely: staring at the browser window for 24 hours, hysterically hitting the F5 key, nearly having a heart attack at the beginning of the official countdown, when the Mozilla Foundation’s servers went down for more than an hour, well I think we’ve all been there.
Strangely, on FF3 Download Day the LilyPond Report’s statistics went through the roof as well — I can’t really understand why, maybe it was because everyone was eager to test his newly-installed web browser...
This special day made another great event stay almost unnoticed: Wine 1.0 is out, after 15 years of development. What’s Wine? It’s an amazing program that allows you to natively run MS Windows software on non-Windows operating systems: 32-bits GNU/Linux distributions, Solaris, BSD,... Photoshop, MS Office, you name it; it even offers (quite impressive) support for a huge number of Windows 3D games!
Wine will undoubtedly increase the GNU/Linux market share among people who want games... without necessarily wanting Windows. But is this event likely to affect the LilyPond world? For several years now, Wine has already had the ability to run Finale or Sibelius on GNU/Linux. Does it make these softwares really more appealing? I don’t think so. People who "just want Finale", most of the time, also "want Windows".
Actually, the improvement of LilyPond’s support for MusicXML, which we discussed last week, might play a much more significant role in making the switch easier between these applications and Lily, no matter the operating system used.
[UPDATE: Just after having written about people who "want Finale" and Windows, I’ve found this hilarious blog post by Matt Asay, saying "If you like WordPerfect, then Windows is what you want. [...] But if you do want to run WordPerfect you have problems that no operating system can fix for you".]
What’s up with LilyPond?
This week an user named Claus Tirel had a short discussion with Mats and myself on the bug mailing list.
As he had reported a bug for LilyPond 2.8.1 (that was released in early 2006), he wondered why we would not process bug reports for this version (nor even for our latest stable version 2.10) anymore.
This discussion that happened afterwards made me understand that Claus wasn’t familiar with the LilyPond releases and debugging cycles, and led me to search for a way to explain it to unexperienced LilyPonders.
Unlike big projects with more resources, that can afford maintaining "old" stable branches for years [2], LilyPond has two branches: the "stable" version (currently 2.10.33, released on September 20th 2007) and the "development" version (currently 2.11.49, released last week).
Software development, if I understand correctly, is made of two things: fixing issues, and implementing new features. Sometimes, the two kinds are actually mixed: for instance, we’ll solve this bug by rewriting this piece of code, adding this new property, etc.
Whenever any part of the code is modified, there’s a risk that something will get broken in the process, or that something will change in the LilyPond syntax. Therefore, the development version is where all the fun happens — but also the risks.
The stable version is released when every major bug has been dealt with, as we’ve seen in last week’s issue. Once it is released, we will keep it up to date as long as we can, but only for modifications that do not break anything nor change anything major: no new feature gets implemented, for instance.
When a bug is reported with a stable release, developers fix it on the development branch as soon as they can; then, given the amount of changes that the fix implies, they have to decide whether this fix can be back-ported to the stable branch or not. In other words, not all reported bugs will get fixed on the current stable branch — in case our users want to benefit from all the bugfixes, we release a development version every couple of weeks.
The LilyPond Feature of the Week
This week’s feature is untested, undocumented and unavailable until the next development release; I was originally planning to mention it as "Idea of the Week" but Reinhold Kainhofer has just announced he had officially "committed" it; so here it is!
You may remember that a few weeks ago Neil Puttock, Nicolas Sceaux and myself had made a snippet that allowed you to add text indications to metronome marks, using a separate function:
Well, thanks to Reinhold and Neil this feature has now been included in LilyPond, and is even integrated with the default \tempo
function:
A tempo indication in general is either a text markup, a note=count or both. So far, lilypond only supported the note=count type of tempo indications in its
\tempo
command.This patch extends the \tempo function to include an optional text string too, which is displayed in the tempo mark. It allows any of the following types of tempo settings:
\tempo 4=120
\tempo "Allegro" 4=120
\tempo "Allegro"
\tempo \markup{\italic \medium "Allegro"}etc.
Kudos! I haven’t yet taken the time to recompile LilyPond and test it, but Reinhold examples look quite promising:
Next week, Reinhold Kainhofer will be the LilyPond Report’s guest.
LilyPond’s Companion projects
A few weeks ago, we’ve seen that LilyPond can be perfectly integrated in different specialized music projects; this week Dr. Peter Chubb, from the NICTA Australian Research Centre, showed us another example of such integration.
Hi folks,
Thanks to Lilypond and a lot of work from the team here, the UNSW/NICTA robot clarinet won first prize in the Artemis Orchestra competition.
What is this competition about?
The Artemis Music Orchestra challenges participants to create devices that play real musical instruments. [It] is an automated-music contest for technical students to demonstrate to the general public what embedded systems can do.
Among others, the contest rules specify LilyPond as the input format, and the instrument has to be unmodified.
The NICTA team chosed to build a Clarinet robot player. Peter gave us a few informations on that robot:
- it has a gumstix running Linux, that does Lilypond and some control loops, which talk to ...
- a robostix that controls fifteen solenoids, an air pressure modulator, a fake tongue and some fake lips to operate the reed.
According to Dr John judge, the project leader, "the Clarinet is a difficult instrument to play: [...] in the design of the mouth piece, we had to control the air pressure going into the clarinet, and the force on the reed".
Here’s the result:
Quite impressive, isn’t it? I also strongly invite you to have a look at the TeamDARE (Netherlands), who won the second prize with a much impressive guitar robot.
Peter Chubb was in charge of the music interpretation algorithms. In the process, this allowed him to write an "articulation" script that could greatly improve MIDI support in LilyPond.
I’ve been using Lilypond for many many years --- you can see my work in Mutopia; I got involved to support Lilypond and for general clarinetty things (as I play clarinet myself).
As I told him that during my Algorithm-Composition series of interview, I had only met people who where quite frustrated with MIDI, he answered:
You’re right, MIDI is very frustrating, but it’s adequate for instrument control ... and after all, that’s what we need for a robot. We chose MIDI as an intermediate language because:
- we could plug in a MIDI keyboard and control the instrument directly
- Lily already has rudimentary support for MIDI output.
Well, congratulations to both NICTA and DARE teams! And of course, many thanks to Peter; we’re all looking forward to seeing some of your work getting implemented in LilyPond...
The Idea of the Week
This week’s idea was suggested on the mailing list by a new user named David Griffel:
I’m transcribing some early classical prints. They use flags which are bolder and clearer than modern flags - at least for 8ths and 16ths.
Would there be any interest in having this as another style of "ancient flag"?
To which Luis Jure added that this was not only useful for ancient music engraving:
Actually I’ve been wanting to ask this for a long time, but not related to old notation styles but rather to more "contemporary" practices: it has been quite common for the last 50+ years to use straight flags (see Stockhausen’s Zeitmasze, 1956).
A few people started to investigate this, mainly Reinhold Kainhofer (again) and Werner Lemberg, who’s our specialist when it comes to font and glyphs issues.
The good news is that LilyPond already makes it quite easy to define and use different flag styles, as Reinhold pointed out:
Actually, adding different flags in lilypond is quite simple: Simply use
\override Stem #'flag-style = #'flagstylename
and lilypond will use the characters "flags.flagstylename[ud][3456]" as flags.Now, to implement straight flags, all one has to do is to create glyphs named flags.straightu3, flags.straightd3, etc.!
Well, I hope this will get implemented; these flags look really nice
The Quote of the Week
This week’s quote is from Hu Haipeng, our "blind musician from China", as he calls himself. A couple weeks ago, we already mentioned his contribution to paper sizes support; this week he told us a bit more about the place LilyPond takes in his life:
I’ll thank you all for working hard on this software. I’m deciding whether I must go to New England Comservatory in USA to study composition, because the deans of my school refused me from learning this when I entered it as their only blind in 1999. Lilypond is the only tool for me to write music. It really helped me a lot!
Such testimonies make me feel happy, and somehow even proud to be (remotely) part of the LilyPond project. This reminds me of what Han-Wen and Jan once wrote in the Documentation’s Preface: "Probably the most important motivation is that our program actually does something useful for people."
As we’ve already seen two weeks ago, LilyPond is particularly convenient for blind musicians. Perhaps it could become even better? For quite some time now, contributors have been investigating possible ways to implement some support for Braille music output.
Ralph Little is the one who’s gone the furthest at the moment; he once told me that one interesting fallout of this feature would be to provide access to the Mutopia project to Braille users, as well as to allow blind composers to compose in Braille.
And this concludes the thirteenth issue of The LilyPond Report.
Cheers,
Valentin Villenave
[1] Speaking of Processing, if you’re interested in it and/or want to test your whole new Firefox 3 you might want to have a look at John Resig’s website, where he has entirely ported it to JavaScript/Canvas. It’s very impressive too.
[2] Some Linux distributions offer an impressive support; not to mention RedHat, that is a company, the community-based Slackware distribution is probably the most impressive: security updates are still released for its seven-years-old version 8!
Valentin Villenave
This author's articles
Forum
-
The LilyPond Report #1318 February 2010, by Sylvain Lafourche
Thank you for this excellent article, with very interesting content.
Congratulation
Sylvain Lafourche from France
-
The LilyPond Report #1311 June 2009, by Peter Chubb
I’ve put the `articulate’ script and instructions to use it now on our website, at
_ http://www.nicta.com.au/people/chubbp/articulate— Peter Chubb
-
The LilyPond Report #1318 January 2009, by Bart Kuijer
Hello,
Excuses for using this possibility to reach you, but I could not find another way.
This is because I’m new in using Lilypond and EasyLilypond and I have a problem. When I want to play the .ly, I see the player works, but I hear nothing. I’m working in a Windows XP environment. I tried it on mij Dell laptop as well on mij desktop, but the result is the same. Do you know a solution for this?
Thanks in advance!Bart Kuijer
Nederland (Pays-Bas)
http://home.kpnplanet.nl/ bart.kuijer@kpnplanet.nl/ -
Steady on with the Finale bashing already22 July 2008
What you and much of the Lilypond world disregard is that most of the people who run Finale are never going to run Lilypond because they simply don’t have the background. The input grammar for Lilypond is complex enough to be inaccessible to most people whose primary area of training and expertise is music pedagogy or music performance. Most musicians aren’t painfully bright and don’t have a background in (or a particularly strong aptitude for) software, formal grammars, or math. True, there is a certain amount of crossover between disciplines but it is not common.
Basic ideas we take for granted like braces needing to match and the difference between a list and a set are lost on these people.
I know lots of choral directors, and they fall neatly into two categories: a) choral directors who could never understand LilyPond well enough to create an SATB choral score with lyrics and accompaniment no matter how hard they might try, and b) choral directors who could if they wanted to but don’t want to invest the time to become LilyPond experts.
I know one guy who is a folk musician and a professional software developer who uses abc2ps instead of Lilypond because he doesn’t want to take the time to learn the syntax.
So don’t bash Finale or Sibelius. They serve their chosen market well despite all their faults.
-
The LilyPond Report #1324 June 2008
Hi !
Thks for this great report again !
Regarding the braille output, I thought it was already in
For example, on this website, in french you stated it is :
http://valentin.villenave.info/Lily..."la prise en charge des partitions en Braille, pour les aveugles musiciens".
What is the real status ?
-
Braille output24 June 2008, by Valentin Villenave
Hence my use of the word "possibilités"... Thanks for having mentioned this paper; though I’ve written it last year it still meets what I’ve written in this issue. The title of the section you’re referring to is "Un projet coopératif, en perpétuelle amélioration", which is precisely what I tried to explain this week.
When I wrote the article you’re referring to, I had recently been in touch with Ralph Little, whom I quote in this Report, and Braille support seemed in a good way to be implemented. He had even already conceived, with Han-Wen, a new kind of translators (like our current Engravers and Performers) called Embossers.
Then Ralph got busy somewhere else and this was not achieved (yet).The way LilyPond is developed, as community-based Free Software, is exactly what makes such an implementation possible; and I’m confident that in an either near or distant future we’ll get this feature implemented, as soon as someone skilled enough, dedicated enough and available enough comes by.
Besides, there’s another feature I should probably have mentioned, that is the support for Festival voice-synthesis lyrics that has been implemented by Milan Zamazal. This feature is virtually ready to be used, as soon as the Festival-side implementation is achieved as well.
-
Braille output25 June 2008
There is another alternative for braille music as well: FreeDots (http://delysid.org/freedots.html) which converts musicxml to braille music.
If Reinhold would get some support with the lilypond to musicxml convertor (http://www.nabble.com/MusicXML-back...), I guess the solution is not far away.
-