LilyPond news

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... :-)

PNG - 5.6 kb

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!

JPEG - 123.1 kb

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:

PNG - 610.1 kb
All these lines were made using only one single function!

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:

JPEG - 6.3 kb
JPEG - 0 bytes

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!


Forum

Home page | Contact | Site Map | | Statistics | visits: 129725

Follow-up of the site's activity en  Follow-up of the site's activity LilyPond Report   ?

Site created with SPIP 2.1.12 + AHUNTSIC

Creative Commons License