Greetings everybody, and welcome to this twenty-eighth issue of the LilyPond Report!
Perhaps unsurprisingly, this installment gives a large place to the first LilyPond international meeting, with no less than three special correspondents reporting on that special event! As for the new LilyPond stable release, we have covered it enough in previous issues so that we can afford to skip ahead today, and give you a glance at our future projects, to begin with: the ongoing Grand LilyPond Syntax Stabilization work. All these, and more, are to be found in this month’s issue.
As always, you can post your comments at the bottom of the page, or send your contributions to the LilyPond Report’s next issues.
Editorial
by Valentin Villenave.
Well well, hasn’t it been a busy couple of months. First things first: the brand-new/shiny/futuristic/pure-awesomeness new LilyPond 2.16 we’ve been talking about for the past year-and-a-half, is here! But more on that below. There are even more exciting news with our very first international LilyPond meeting having taken place in Germany in late August, which you’ll read all about from several key members of our community. Several key issues where discussed, and some wilder long-term ideas were raised (among which, a better integration with the Mutopia project, or a LilyPond-dedicated Kickstarter fundraising dedicated to publish authoritative editions of an ancient music score). One minor disappointment this summer resulted from our involvement in the Google Summer of Code (see LilyPond Reports #25, #26 and #27), which (partly due to unforeseen, sad circumstances) did not fulfill everything we had hoped for. But if anything, this only gives us something else to look forward to next year!
With so much excitement lately, the question remains: what to do now? Well, there are a number of ambitious plans ahead, some of which may have already started on our development mailing list. Now is the time where people are gathering ideas, comments and testimonies, to determine what would best fit LilyPond’s future and our (potential) users’ priorities. The Grand LilyPond Syntax Stabilization project (GLISS), first imagined by Graham Percival no less than four years ago, is now in action (in all its glorious messiness, so far — more on that below) and one can only dream what it will bring us!
Well, perhaps not only dream: as a matter of fact, you can help too. We’re always actively trying to make it easier for new contributors to join us; there is a position for everyone depending on your time and skills (and most importantly, your adventurousness); even if you feel like you’re missing either or both, our senior developer David Kastrup is less picky and simply relies on... your checkbook. Isn’t life sometimes brillant in its simpleness?
Release news
by Valentin Villenave.
You wanted it? There you have it. LilyPond’s stable version is now 2.16.0 and we really, really do encourage you to go ahead and take the leap. Of the hundreds of changes and bugfixes, most will probably appeal more to the advanced user or programmer (or, you know, your average free-software geek); there are, however, quite a number of changes that will make you realize what you’d be missing out by overlooking our newest, greatest release yet.
And that’s not all! Development has evidently not halted, and as soon as 2.16.0 was released, the new 2.17 development cycle issued its first unstable release — we’re now at version 2.17.4 on the development branch (and counting). This branch is, obviously, intended for testing purposes and not production use.
Investors’ report (1)
by David Kastrup.
[Editors’ note: With some delay, here are the results of senior developer David Kastrup’s continued call for funding, and the development activity your donations allow him to pursue. You will find the (more recent) August report further down below, and September results will be included in our next installment.]
Let’s look at the numbers for July. Again, the report could have come earlier, but there has been a lot of ongoing work that seemed rather important to get done. I’ll get back to that after the numbers. Again, I have not separated one-time payments and regular payments (excepting the variable payment plans) in order to get a picture fast, and all payments are attributed to the month they arrived in.
| Fixed payments (€) | Variable plans (€) |
|---|---|
| 180 175 2×100 50 30 3×25 2×20 5×10 |
25 + 50 (target €1200) |
| Total: 800 | Total: 75 |
Now the good news is that with the May&June report late and no additional announcements, my needs have been met, partly due to a one-time payment of €175, but mostly due to the faithful keeping up donations.
The bad news is that medical insurance will likely put me down as "self-employed" rather than "subsisting" soonish, gobbling up another €150 per month since they are then basing their payment rates on an assumed `minimum’ income of about €1300 per month.
I’ll try finding some more people willing to sponsor the work I do on LilyPond, but it makes sense if you help spreading the story.
Results
Now what has actually happened in July? A lot, actually. There has
been a flurry of bug fixes and improvements across the board regarding
programming interfaces, some performance fixes, and several cleanups
of LilyPond syntax. Several programming interfaces dated from the
time where Guile did not yet support rational numbers as a native
number type, and I’ve made progress in simplifying them in connection
with musical moments.
Quite a bit of effort was spent on strategic discussions in the mailing list again: some concerned the way we want to see LilyPond syntax heading, with a view of providing long-term stability.
But the most pressing topic of discussion was likely centered around our stable release criteria. As the main result, I have let myself get appointed dictator for the release of the overdue stable version 2.16. Just as of this writing we have seen the release of 2.15.95, the last unfrozen development release in the 2.15 series. The stable release branch has been split off from development, and the next release created from the development branch will be 2.17.0. Any further 2.15 releases will occur from the stable release branch, and only to cure absolutely release-critical conditions before releasing 2.16.0. The release 2.16.1 will likely happen about a month afterwards, to integrate fixes that have seen exposure in 2.17.0 and found to work well.
A plausible release date for 2.16.0 might be during the developer and user meeting for LilyPond in Waltrop at my place, happening from August 24th to 28th. LilyPond build script magician John will be present as well as project leader Graham, so releasing 2.16.0 as part of the meeting course work would seem quite feasible if nothing really forbidding intervenes.
Outlook
It is not clear to me yet how things will continue. I am glad for the
time I have so far been able to spend on LilyPond thanks to the
commitment of a large number of people sponsoring my work, and I think
that LilyPond is seeing reasonable benefit from its results. After
the efforts for releasing 2.16 and having the meeting at my place will
peter out, I expect to pick up work on LilyPond syntax again and be
able to finish most of the music function work in one or two months of
time.
I also would like to continue with the work reorganizing context, context definitions and other LilyPond internals: this can’t really be done in small parts. I tend to work on that in bursts of one or two weeks at a time, so it will likely still take several months before something ready to test will arrive from that.
And of course, there are lots of smaller things always cropping up and getting solved. If you take a look at the bug tracker, you’ll see that there is no shortage of issue reports, and I do a fair amount of solving problems reported by others as well as those `invented’ by myself. And that further slows down some of the `big’ developments.
The month-to-month uncertainty of making ends meet even while several people are taking large personal investments (and not only monetary ones) remains troublesome, and I don’t really feel like reaching the point where I would say ``now everything I wanted to see done is finished’’ anytime soon.
Just recently news made the headlines that Avid, the owner of the proprietary notation software Sibelius, closed its Sibelius development headquarters in the UK, discharging the original developers. An offer by them to buy Sibelius back from Avid was refused, so they are not allowed to continue development independently. If dispensing of the expertise from the previous core programming team including its creators is supposed to make economic sense, it seems unlikely that serious further development is planned.
Now while active development of LilyPond certainly has moved through a number of hands as well, nobody is getting locked out from it. And even non-programming users have the guarantee that the code remains available for bug fixing and further developments, and that they can hire programmers should business and/or their private score collection depend on it.
Compare that to the consequences of proprietary business models: the right to make such an offer has been bought off the creators of Sibelius.
A Postcard From Waltrop
by Graham Percival.
The Waltrop LilyPond meeting was fantastic. I’ve met other LilyPond developers before (Bordeaux in 2010, Paris in 2011, Linz in 2012), but this time it was on a completely different level.
- From left to right: John Mandereau, Graham Percival, Jan Nieuwenhuizen
I think there were two reasons why it felt so different. First, it was a multi-day affair with computers, rather than meeting people for an afternoon or two while sight-seeing. There’s nothing wrong with purely social affairs, but sitting side-by-side while working on LilyPond gave me much more of a feeling of teamwork. Second, there were enough people there such that I could watch the interactions of other developers. It was fascinating to watch small groups working, such as Jan and John fighting with GUB, or Mike and Janek passing patches and regtests between each other to find and fix bugs in the vertical skyline. There was a mixture of technical LilyPond discussion, tips on tool use (git, emacs, scripts), and jokes about pineapples.
I was also blown away by the speed Mike and Jan’s workflow. I’ve always considered myself to be a fast typist and fast at switching between windows and desktops, but they completely outclass me. I was particularly stunned by Mike, since he was working inside a virtual machine! The best analogy I can think of is an organist. I’ve seen skilled pianists all my life, but the first time I saw a skilled organist up close — playing on 2 or 3 keyboards, twiddling the stops, playing pedals... all with a delay of a second or two — my jaw almost dropped. I’m not trying to start a fight about which instrument requires the most skill (how can we really judge the "skill" of manipulating keyboards vs. manipulating vocal cords, tongue, lips, etc?), so let’s just say that the organ has one of the most *visible* displays of skill.
I didn’t get a lot of work done on the weekend. I have trouble concentrating when there’s people talking around me unless I completely drown them out with really loud music in headphones. I considered moving to a different room to work, but that would have been really antisocial and I wasn’t really planning on doing much work anyway. I viewed it as a holiday from my PhD, so I was happy to "hang out" in the main room and do incidental tasks. I’m glad that I stayed in the main room, though — I feel more enthusiastic about LilyPond than I have for the past year or more. I’ve only been "going through the motions" for the past few months, but that’s changing due to Waltrop.
I definitely hope it happens again. The energy was incredible, and it made me wonder how much LilyPond could improve if we had regular face-to-face meetings. It’s not possible given our world-wide nature of our developers and contributors, but it’s an interesting thought experiment. I’m a bit sad that I didn’t try harder to organize a British LilyPond meeting, but it’s too late now as I’m leaving the country in a few days.
- Graham Percival (looking surprisingly confident.)
From Waltrop with love
by Janek Warchoł
- Breakfast time.
I am very happy that i participated in Waltrop meeting. It was the first time that i’ve seen any of the developers in person - in most cases i was quite surprised! Granted, i’ve talked and collaborated with you for about two years, but in text-only communication people appear differently than in real-life (now, that’s not an impressive discovery :P). I think that Graham was the one who surprised me the most - turns out that he’s not that grumpy after all! Did you know that he can actually be enthusiastic about some LilyPond proposals? (if you, dear reader, are now thinking that i must have had hallucinations, i assure you that i’m 100% sane!)
Also, i think that i can understand other developers significantly better - i just imagine them speaking whenever i’m reading an email from them, and bang! 50% better understanding
Yes, i think that may be one of the most important results of the meeting - more effective communication (as English isn’t my native language, i’m never sure if my messages are clear enough - it was great to have real-time, visual feedback from other people on what i say).
There are some measurable effects, too - i got interested in GUB, and when i’ll receive my shiny new laptop [it’s actually a ThinkPad, so it won’t be shiny in any literal sense
All in all, i believe that together we can craft the best piece of music software in the world!
Janek "the Pineapple Man"
Impressions from the Waltrop meeting
by David Kastrup.
In a nutshell, the meeting quite surpassed my wildest expectations. Partly due to my lack of insistence, a few weeks before the meeting it looked like Graham, Marc, Harm and myself would spend some leisure time with each other, and that would be about it. But then with Mike, John, and Jan a critical mass of heavy-weights enrolled, and furious activity ensued.
Friday
On Friday, basically between
Graham and John the release of 2.16.0 was getting under way, completing more or less by
noon, starting the whole meeting off with a large boost of excitement,
motivation, and a sense of entitlement. Janek started to install and
compile GUB, LilyPond’s Grand Unified
Builder on his machine, a process continuing in the next days and
spreading out to more machines, including one dedicated for future
release work from my place. With Mike, and later Jan arriving on
Friday, the plan was to release 2.17.0 running with accumulated updates
to the build system in the evening.
- Leaving the evil bright yellow thing outside
It turned out that this was quite a bit too optimistic and that my resistance against admitting any non-trivial work into the 2.16.0 release after 2.15.95 had been prudent, even though the freezes I put down were rather abrupt and provided little opportunity for firming up 2.16.0 better. Soon after splitting the stable release branch off early in August it became clear that several small regressions would require non-trivial fixes, and that exposing them in an unstable release before reintegrating them into the stable branch would be desirable. So there was (and is) definitely a release 2.16.1 going to happen in due time, and clamping down hard on 2.16.0 was opportune. The alternative of softening up the freeze until the last fixes were in place was something we tried for about a year again and again: without an unstable release series serving as a testbed, it did not work.
In this manner, we were able to ride on the euphoria of having released 2.16.0 early in the meeting. Nothing seemed impossible, and the programmers tended to stay busy until late at night, or early morning, with vigor working on 2.17.0, making GUB run on several systems, and in the last night, integrating Mike’s large skyline work. Graham had set up his bed in the meeting room and alternated between sleeping, working, and overseeing things.
Weekend
Saturday saw the arrival of Karin Höthker and Dominik Hörnel from the
Scorio project (see below). A lot of discussions ensued, a tablet computer with a score application was handed around, and the LCD projector rented for the meeting was put to use. In other departments, Rodolfo assumed the reins in the kitchen, resulting in a marked increase in food quality at lunch (pasta and salad) and dinner (barbecue).
Increasingly the importance of having LilyPond support MusicXML for output became obvious. Patrick Schmidt from Philomelos, arriving on Sunday, did nothing to detract from this impression, and neither did Nils Gey, the Laborejo head honcho (see The LilyPond Report #27).
Another recurring theme was the stability/dependability of LilyPond
syntax. Neither of those projects ended up using LilyPond as their
storage format. Philomelos, when importing LilyPond, uses
\displayMusic to print it, then parses the resulting Scheme code using a parser written in another programming language (could have been PHP but I don’t quite remember). The Philomelos GitHub account sports a
fork of the MusicXML exporter from LilyPond, so it would not seem like
this is the only strategy, or maybe I just confused things. Scorio uses
LilyPond just for export and typesetting, and looking at their web page
listing the used
"Open Technologies", there is a notable absence of LilyPond. It is
mentioned on the Platform page, though, which makes it likely that this somewhat
disconcerting omission is not due to hiding credit where credit would be due, but rather due to the lack even of self-inflicted standards
LilyPond obeys.
Harm had arrived on Saturday, but although he indulged in some bar line customization work with Marc, the main focus of the conference activities turned out to be not in the Scheme/Guile department. An embarassingly large part of the conference appeal might be described as "Wifi and AC power", and the developers taking things from there. The flurry of release and build system activity culminating in the release of 2.17.0 on Sunday and the followup integration of Mike’s skyline patch on Monday and the release of 2.17.1 in the following night concluded the storm of development activity.
Apart from the various coding parties, another important aspect were the frequent discussions about where corporate users of LilyPond were seeing problems affecting their workflow, and lots of discussions about where we see LilyPond heading.
A recurrent theme were the question what to do about knitting LilyPond into the music fabric of the Internet, and what to do about Mutopia ailing rather than profiting from the increasing growth of user-provided content management and/or crowd sourcing.
We had Han-Wen on phone conference from Brazil on Saturday night, but connection quality and lack of physical presence (creating a video connection was not reasonably successful) turned this more into a radio-amateur-like experience rather than an interchange with a high level of interactivity. While the phone conference petered out, I brought Karin and Dominik to their hotel in Datteln, having to drag Conny from the car in the process where she had sought shelter from the thundering voice of Han-Wen permeating the house.
Monday
On Monday, Patrick brought in Julien Lerouge, the programmer responsible for Philomelos’ import of LilyPond (if I understand correctly). I did not actually follow most of the discussions that happened on Monday since most happened in small circles. Also, I was somewhat exhausted, and intermittently trying to get GUB to work on a donated computer.
Tuesday
People left by and by. Hopefully not too many were affected by my
mischaracterization of the local transport ticket vending machines
(which did require stamping even single-person tickets before
use, contrary to more central ticket vending machines). I don’t think
that any party dropped off at the subway station had more than 1 minute to spare except for John.
- Coding party.
Summary
- The good
The meeting was quite productive regarding work on LilyPond. It was particularly helpful that Jan, as the author of GUB, LilyPond’s Grand Unified Builder and one of the LilyPond founders, was working together with John to bring some of the requirements forward to newer systems.
It was great meeting all the people one knew only from mail communications and associate a face and personality with them.
Indeed, not all that many of the participants had previously met with Jan. It was particularly nice to see him enthusiastic about the meeting itself, the people he met, and some newer developments and possibilities, like when I showed the amount of introspection possible using the Scheme sandbox and the much energized#{...#}to repeated interjections of "It’s beautiful!".
While organization was rather on the thin side, the meeting attracted American, Canadian, Dutch, French, German, Italian, and Polish participants from France, Franconia, Germany, the Netherlands, Poland, Scotland, and Switzerland. - The bad
There were quite a few lost opportunities.
The picturesque surroundings were not really keeping anyone distracted for any significant amount of time. Most participants probably did not likely traverse more than 20m² of ground during their stay.
Apart from Marc’s wife Tine, nobody actually got to see the town of Waltrop exhibiting its main yearly attraction in the form of the Waltroper Parkfest.
The lack of a prepared talk schedule resulted in a dearth of "entertainment" for participants not currently coding. Having talks and discussions in parallel would not likely have distracted the focus of the coders significantly, so this was a bit of lost opportunity as well.
There were too few interactive sessions focusing on the exchange of programming, music entry and debugging techniques and establishing standards for coding and review.
Apart from my own Thursday evening icebreaking attempts, no music was actually performed during the conference, probably in order not to prompt repeat performances.
My lack of planning (and sleep) did not always lead to the most convincing results in the food department. Part of that was softened by our favorite Indian fast food joint which even provided "typically German" fast food in the form of "Zigeunerschnitzel" and "Hawaiischnitzel" to those participants who would have been loath to leave without a taste of German fastfood classics.
The lack of organization ahead of time lead to a somewhat random collection of guests and interests and probably made it hard to get affordable transportation. On the other hand, finding sleeping places for a significantly larger assembly would likely have been difficult. - Conclusion
I think that the meeting was an important step for refocusing on our common goal. Most of the participants had fun: basically all of them had to be dragged from their computers and to the subway in the last possible minute. I hope that this fun will stay with people and carry them to our next meeting. Even though the participants did not get to leave the house much, the meeting place was adequate for our purposes.
I consider doing this again next year. Maybe I should offload part of the organizational burden next time in order to increase the meeting’s effectiveness.
Investors’ report (2)
by David Kastrup.
So here, somewhat late are the numbers for August. Let me first state that I am carrying over an impressive €420 payment "to be distributed as I see fit" into September (see below) as it appears more necessary there. So this is not included in the August numbers. Apart from this rather large sum, the Waltrop meeting more or less carried itself. I set a "conference fee" target of €10 per day and person. This might have been overoptimistic on the days we ordered food, but attendees tended to round up, and there were some donations dedicated to the meeting (including covering the LCD projector). For mixed donations and meeting fees, I have deducted the nominal daily fee before listing the donation. So the meeting is accounted for.
| Fixed payments (€) | Variable plans (€) |
|---|---|
| 175 160 152 119 100 3×80 75 70 60 40 39 32 30 5×25 20 15 2×10 |
25 + 50 (target €1200) |
| Total: 1472 | Total: 75 |
Now that’s rather amazing, and of course the single variable plan is down to €25 for September. There are a few other amazing things: most of the larger contributions have been from previous contributors, making their total contribution quite larger than what appears in the monthly statements.
One of the larger single amounts was from somebody who is taking his vow of poverty and considered it appropriate, as he had been making use of LilyPond for creating readable score sheets for brethren with worse eyesight, to take LilyPond’s development into consideration when divesting himself of his last possessions.
Again: I continue being amazed at your support, and it is rather uplifting to see that continued amount of support and dedication. The question is how to stabilize it: if everybody now thinks everything is in safe waters, it won’t be. So again I want to remind people of the possibility of pledging a variable payment plan, where the payment depends on the situation in the past month.
I have taken the opportunity of actually taking a look at my personal financial situation. My original statement of a minimum of €800 for continuing on LilyPond was somewhat optimistic: with rent (about €400 including energy, phone, and internet) and insurance and other fixed costs, about €600 were already gone (and insurance, as told last month, is going up), and that leaves about €7 per day for food and similar niceties. It turns out that my bank account from the middle of September, as compared to March, has dropped by a mere €200, while the remaining unconverted PayPal balance in $US is a bit above €1000. However, pretty much at the start of this period, our "shopping accounting" for close to a year was done, and I got about €600 out of that as I am mostly the one of us two buying food.
So it means that even with the spectacular August balance (including the carry-over amount), I have been scraping even. In that time, I took one conference trip to Chemnitz (for a LilyPond conference), and a 10-day climbing vacation with friends in Italy at a rather affordable apartment. Not all that much of luxury. And there will still be taxes to pay, as your support puts me above the poverty line regarding the German taxation system.
The €800 projected sum (which was pretty much what the monthly average of the previous months had been) was just that: an amount allowing me to break even, and with the bit of cheating in August, it did do so before taxes. But if you consider contributing to a variable payment plan, in the interest of long-term sustainability I would suggest specifying the target sum after which your payments are allowed to decrease somewhat higher as I don’t really see all that much wiggling room for further cutting my expenses.
While it is too early for a detailed report on September’s results, latest numbers show a sharp decline. However predictable that decline was, it confirms how fragile this system remains, and how your constant involvement and benevolence is needed.
Results of August
The main focus in August has been the developer meeting at my home in Waltrop (see above), and its results. LilyPond 2.16.0 was released on that meeting as well as 2.17.0, and 2.17.1. The preparation of the 2.16.0 release had been left to my discretion after extensive discussion, and while there are still some cleanups requiring a 2.16.1 release, its overall shape appears fine to me, and being able to start the meeting off with releasing it was quite important for setting the mood. So no regrets here, and it is definitely quite a step forward for our users.
While I managed to get off the wrong foot for much of the after-meeting discussions and work again, I still think that having met personally will help everybody manage to get a broader perspective concerning the shortcomings of our communication.
What’s happening now
So this was rather uplifting, and the mood of the Waltrop meeting also
helped. Back into development, the atmosphere on the mailing list,
after initial revitalization, has become strained again. To a large
degree, this is attributable to my manner of handling proposals I do
not consider fit for inclusion into LilyPond.
Discussions about syntax changes have been opened, and since my own priorities are set on consolidating the current state and possibilities while many of the suggestions don’t really fit well with current and planned developments or overall consistency, I have spent an extraordinary amount of time and energy mostly discouraging proposals or expounding on the problems they would cause both in their own implementation as well as when considered as part of a whole.
Let’s just say that I have not really managed to do this in a manner that has been well-received.
Ongoing tasks
It turns out that syntax changes are continuing, with much of the
patches being somewhat obtuse in the description. I expect to spend
at least the next month on continued cleanup and reorganization, with
the goal of making user-definable functions a much more versatile and
ubiquitous tool than they are now.
There are some discussions about various syntax changes, and some of them are more implementable or useful than others. Those that are both of more invasive nature as well as worthwhile will likely have to wait until I finished with my ongoing reorganization work, as they would get in the way before this is reasonably finished.
After the syntax has been done, the property system is still in for an overhaul in order to make it work more closely to expectations. There are currently surveys planned in the national user lists and forums for LilyPond regarding the problems people have using LilyPond, but some of the preceding discussions indicated that this is an area of interest.
And the Guile v.2 migration is also going slowly on intermittedly. In all of those areas, I consider it important to be involved, and your support allows me to do that.
Online Typesetting with LilyPond
by Karin Höthker and Dominik Hörnel.
At the Lilypond developer meeting in Waltrop we presented our online music editor (see The LilyPond Report #24). We talked about how we attempted to tackle the performance problem one inevitably gets when developing a WYSIWYG music editor with Lilypond. Typesetting remotely on a server adds to the problem. In the meantime we have done some measurements that we will present in the following.
When starting with scorio, we quickly agreed on LilyPond as our music typesetting engine because of three major reasons:
- its beautiful music engraving
- the ability to produce scores from semantical music information without the need to specify a lot of graphical details thus avoiding extensive re-work with adjusting text, slurs and other notation elements afterwards
- because it can be extended and integrated into a GUI-based note editor.
At first, it was not obvious how to achieve a round trip in an acceptable time involving
- typing a note into an editor,
- sending a request to a server,
- running Lilypond on the server,
- sending the result back to the client and
- displaying the result in the browser.
Although there are excellent editors supporting input of Lilypond syntax and Lilypond compiling (like Frescobaldi), it is hard to find WYSIWIG editors for Lilypond (Denemo is an example). One reason may be that LilyPond offers an input format that is excellent for writing music in a text editor, but challenging as far as automatic score manipulation is concerned.
In the following section, we briefly explain the round-trip in scorio and how we attempted to master the performance issue.
Score manipulation
As mentioned above we decided against doing edit operations on LilyPond source files.
So, we had to look for an alternative representation. For a short moment, we thought about
developing our own internal music format, but soon rejected the idea: Why re-invent the
wheel? Furthermore, we would have locked users in into scorio, since import from and export
to other music formats had yet to be written. We were rather aiming at setting up an open
music notation platform, where users could import existing scores, edit and share them online,
and later export them again to their favourite notation program.
So, we ended up using a slightly enhanced MusicXML format as our internal representation. Although not perfect, MusicXML makes score manipulation, import and export easier as it has become a de facto standard in music notation industry supported by all major notation programs. The graphical representation in scorio is pure HTML and therefore makes it possible to use scorio in all major browsers on every platform (PC, Mac, and even iPad). To produce HTML for a LilyPond score we wrote our own HTML backend as an addition to the existing Postscript and SVG backend in LilyPond.
- Figure 1: Score manipulation round-trip
So the round-trip basically works as follows (see figure 1): When the user clicks into the score, an edit command is created, e.g. “create new note before existing one”. The edit command inserts the note into the MusicXML tree. Then the MusicXML tree is converted into a Lilypond file and processed by LilyPond. The HTML backend produces an HTML page and finally sends it back to the editor. The rendering of the score is done by the browser.
The HTML representation of the music piece mainly consists of images. However, the client needs more information in order to decide what action the user wants to perform next. For this purpose, the HTML contains additional attributes attached to each graphical object (or grob) of the score. For example, its part and staff are attached to each note. This is achieved by adding “annotations” when generating the LilyPond score. Annotations are created using a custom \annotate command that adds them to the Scheme music tree. In this way they will be attached to the grobs they belong to, and can be added to the HTML in the HTML backend.
The following excerpt from a generated Lilypond file shows an example of annotated Lilypond:
\score {
<<
\new Staff="'((sc-part . P1) (sc-staff . 1))" <<
\new Voice {
\numericTimeSignature \annotate #'(
(sc-id . 1298541892071_0.6492787506599623)
(sc-beats . 4)
(sc-beat-type . 4))
\time 4/4
}
\new Voice {
\annotate #'(
(sc-id . 1270804615382_0.44181689312608075)
(sc-part . P1)
(sc-staff . 1)
(sc-voice . 1)
(sc-fifths . 0)
(sc-mode . major))
\key c \major
\annotate #'(
(sc-id . 1270804615379_0.08310412084356789)
(sc-part . P1)
(sc-staff . 1)
(sc-voice . 1)
(sc-sign . G)
(sc-line . 2))
\clef violin
\annotate #'(
(sc-id . 1270804615382_0.06348578421654139)
(sc-part . P1)
(sc-staff . 1)
(sc-voice . 1)
(sc-step . C)
(sc-octave . 5)
(sc-note-type . quarter)
(sc-duration . 480))
c''4
}
>>
>>
}So far, we have seen the editing round trip. The performance problem however is still open.
Improving performance
The round-trip works well for smaller scores. But as the score is growing larger and larger
the performance significantly drops and makes editing practically unusable when rendering
the entire score after each edit command. We also noticed that the Lilypond processing time
does not increase linearly but superlinearly with the size of the score due to the calculation of
optimal line breaking in LilyPond.
To overcome this performance issue we use the \skipTypesetting command. It allows
producing graphical output for an excerpt of the score thus almost reducing the time
consumed for typesetting to this excerpt. Consider a user working on a system in the score.
As scorio shows one page at a time we may skip typesetting for all other pages. Even more,
if the user is editing notes on a specific system it is not necessary to update the entire page
each time but rather the system on which the user is working. We therefore do typesetting
for this system only. After the user has finished working on the system s/he may refresh the
page and later the entire score. We call this concept partial update: When an edit command
is performed on a system, typesetting is restricted to that system (system update). In case
the edit command produces more than one system due to a system break, a page update is
automatically performed. Only in case an edit command influences the entire score such as a
score transposition, or if the user manually refreshes the score, a score update is performed.
The following figures show some measurements of the LilyPond performance with score, page, and system update. The sample score simply repeated the notes Bb-A-C-B up to a maximum of 20 pages.
- Figure 2: Runtime performance with LilyPond.
As can be seen in figure 2, the runtime increases superlinearly (quadratically?) with the number of pages.
- Figure 3: Page update with LilyPond.
In figure 3 however, creating one page took about 3 seconds. When increasing the number of score pages, but typesetting one page only the runtime slowly increases linearly. Rendering one page on a 20 page score took about 4.4 seconds.
- Figure 4: System update with LilyPond.
Similarly, in figure 4 creating one page took about 1.5 seconds. When increasing the number of score pages, but typesetting one system only the runtime slowly increases linearly. Rendering one system on a 20 page score took about 2.4 seconds.
Conclusion
We have described how the online music notation site scorio.com typesets music with Lilypond running on a server. Performance measurements show that the approach works well
for smaller scores. Since scorio’s user interface is designed to be as simple as possible, it
targets users who want to typeset music with only little training and typically would like to
typeset short musical pieces for daily use rather than extensive compositions.
At the same time, we feel that there is still room for improving the performance of the most
widely used operation in scorio: editing a single note in a system. 200ms – the reaction time
commonly perceived as fast in user interfaces – may be out of reach. But a turn-around
duration well below 1 second would improve the user experience.
LilyPond Syntax oddities
by Valentin Villenave.
Let’s be blunt: for the past couple of years, I haven’t been as much involved with the LilyPond project as I’d love to (or at least, as I used to love to). I never stopped using LilyPond obviously, but the discussions, the developments, so much intelligence and brightness flowing up everyday on our mailing lists, that was just more than I could handle.
Recently, I happily accepted a commission from our contributor James Lowe to create an orchestral score for him. Since he told me the violins in his orchestra were mostly beginners, I thought I’d use quite a lot of open strings; so I thought, hey, there must be some sort of a shorthand for that. Since d-> produces an accented note and d-. produces a staccato, I had reasons to hope that, say, d-° would print an open string.
And it did.
Now, James being a LilyPond connoisseur of sorts, I thought I’d send him the .ly code instead of a PDF. And since I was using a fairly recent development build, there was hardly going to be any problem for him to compile my code, right? Right. Except... he couldn’t.
Because what I had been using was actually not a known shorthand, but an almost-undocumented feature of LilyPond that allowed people to print markups without using double quotes. And the ° character I mistook for an "open string" sign, actually was just that: a single-character markup. And thanks to David Kastrup clarifying the lexer and getting rid of this undocumented feature (that looked, actually, like a bug or an inconsistency of sorts), the newest version of LilyPond — the one James was using — would have thrown an error, thereby forcing me to clean my code, and use the actual, proper \open symbol instead:
What I mean is: syntax consistency does matter. To all of us, even to experienced users like myself or James. Granted, all of us do not have much time to spare for such discussions. But there _should_ be a way for as many people as possible to gain awareness and take part in this collective thought process. This cute silly story of mine actually predates the Grand LilyPond Syntax Stabilization project that is now in action (for better or worse, see below), but LilyPond is full of such undocumented half-features/half-bugs.
To wit: we recently mentioned the empty chord construct, which may be one of the nicest of those; however, look at another undocumented oddity David has just exposed:
xxx #'j #'k #'l = 7
#(format #t "xxx = ~a\n" xxx)
xxx = #'()
xxx #'j #'k #'l = 7
#(format #t "xxx = ~a\n" xxx)
Not for the faint of heart, eh?
LilyPond Syntax discussions
by Valentin Villenave.
So, the GLISS project is finally here and people are chiming in with their suggestions. Whilst it had been suggested that these discussions ought to take place on a mailing list of their own (a list I opened four years ago but that hasn’t seen much activity), it has been decided that our regular lilypond-devel mailing list would do just fine, provided that mail subjects are neatly prefixed with [GLISS] for general-purpose gliss-oriented conversations, [talk] for informal talks, [proposal] for more carefully thought-out ideas, etc.
It does make for very technical, high-density, high-volume conversations; some generous souls have offered to keep regular users posted (particularly users who don’t speak English on foreign mailing lists) but that doesn’t change the fact that our -devel list, which was already quite crowded, is becoming somewhat of a mess — where some discussions tend to become heated (as David mentioned above).
Here at the Report, we’ve been receiving a few letters from people involved in these discussions and wondering if there could be a better way to handle these discussions. Here’s what Ian Hulin (who has been working on several proposals for a new tuplet syntax) had to say on the matter:
I reckon what has happened has provided us with some useful insights.
Using this process maybe allows us to capture the WHY of a development feature rather than answers to WHAT and HOW which is often what is documented, if it is documented at all.
- Unless someone takes ownership of a discussion and is prepared to spend time moderating it, it will tend to peter out and go nowhere.
- Being a moderator can be like being a eunuch in Imperial China: they knew an awful lot about sex in great detail but couldn’t do it themselves. Moderating a discussion means guiding developers to a consensus and then finding one of them comes up with one which does 90% of the job (cf. Keith O’Hara’s latest post).
- Moderating means you’ve got to be prepared to repeat yourself an awful lot.
- Moderating means you’ve got to be patient, and you’ve got to be infinitely polite.
- Moderating also means you’ve also sometimes also have to be deliberately stupid so you can get a particularly enthusiastic developer to dump a bit more out of their head into writing so the rest of can buy in to what he’s thinking.
- Moderating means keeping track of the discussions and producing a and constantly refining a proposal until it becomes a design doc for the feature. We could also use it as the basis for entries in NEWS if the feature needs one.
- Using [talk] only really works if we use it as a sub-list of -devel.
- Moderating a proposal means spending time on it, which you may feel could be spent on implementing it. It’s actually quite difficult to do (hence the eunuch reference above).
This somehow meets another proposal by Janek:
i suggest to visibly separate discussing problems from discussing solutions. Currently we are mostly discussing ideas for syntax, i.e. "let’s have syntax X doing Y". I suggest that for several weeks we shall focus on "i find syntax W confusing" and "i find notation Z difficult/inconvenient to express in current syntax" instead. We would add syntax problems that we identify as issues to the tracker. [Editor’s note: David isn’t sure the tracker would be an appropriate place for that, and I tend to agree.] After we’ve finished gathering them, we’ll sort the issues and *then* we would discuss how to solve them.
Why do it this way?
- we’ll see the big picture better
- we’ll be able to schedule the discussions about solutions, so it’ll be easier to participate in them
And perhaps most importantly: when someone posts a syntax *idea*, there’s a chance that syntax experts will reply "omg wtf?! this won’t work". This leads to frustration. On the other hand, if we discuss our *problems*, syntax experts can just answer "it would be reasonable to solve it this or that way" - and voila! less frustration.
So, where do _you_, dear reader, stand on these issues? Is the current way appropriate to you, or do you feel somehow left out? Is there a place that would seem more likeable, more convenient, for these discussions, that you can think of? Or is it a purely human problem (assuming, of course, there is a problem at all)? Like many times in the past, the LilyPond Report intends to help however it can, by gathering opinions, synthesizing current debates and providing its readers with both the latest topics at hand, as well as a place to comment on them while taking a step back.
That concludes our twenty-eighth issue of the LilyPond Report.
Cheers,
Valentin Villenave, Janek Warchoł, Graham Percival & David Kastrup.
