Music is an important aspect of any digital encyclopedia, and ogg files are surely the right choice[citation needed] when it is important to hear the original recording, speeches, singer voices and other effects. But sometimes, it is better to host not the audio file, but the sheet music itself.

The Lilypond feature of wikitex does exactly that in an elegant wiki way. Musical notation made simple and editable, as a true wikipedia article. And it automatically outputs either a graphical printer-friendly sheet music or a hearable MIDI file , which normally is only a few bytes long, as it is transformed into music by the visitor's computer, saving wikimedia's server space and bandwidth. The new Music:Namespace can be used and all music would be inserted in {{Music:name of article}} templates, so as not to clog original articles.

A standardized way of encoding musical notation has proven to be an elusive goal, despite a clear demand and a good deal of technical attention. The difficulties are that:

Music notation is inherently more position-sensitive than text. Text is sequential; it is made up of symbols that are displayed in order. Except in special cases such as poetry or scientific formulae the relative location of symbols carries little meaning, aside from simple paragraph breaks, subscripts, and superscripts. Music, on the other hand, is written using symbols that have important relative relationships; a note above another note means something different than the same two notes spaced apart horizontally.

Music notation is not completely standardized. Expressive words and marks, unusual meters, clefs, staff arrangements, and noteheads complicate the effort to define a context-free grammar for describing music.

Unlike scientific formulae, musical notation can be lengthy, running to dozens of pages for a single movement. Determining proper spacing and proper use of line breaks is difficult.

Even considering only those aspects of music notation that are quite standard, there is a great deal of complexity to the notation system. The alphabet of symbols used is larger than the Latin alphabet, and there are a wide number of attributes that relate to a staff or note.

Layout requirements vary from one piece to the next and are a matter of judgement. Some types of classical scores are printed with very little space between the notes. On the other hand, many popular music scores are printed with considerable white space.

Evolution of a standard has been compromised by multiple, competing, proprietary systems. The proprietary systems interoperate to a degree through use of converter programs, and their vendors have not supported any serious attempt at a standard.

The most prominent open-source music engraving tool is Lilypond, which defines its own input grammar. There has been little interest in using Lilypond's grammar as a standard, perhaps because it is frequently revised.

A music Tex project was once undertaken but appears to be dormant at this time. Other efforts have included Humdrum and MuseData.

Efforts at a standard called MusicXML are underway but have been greeted with less than total elation by industry and users. Key parts of the standard are protected by copyright and available under the terms of a license that, while free, creates compatibility problems with other major free licenses.

Most on-line distribution of scores is done using bitmap graphics files (e.g. PNG, JPG, GIF, TIFF) and formats such as Postscript and PDF. All of these are graphical formats that define elements to display on a page; the underlying structure of the music is lost. As such, possession of a PDF file for a piece of music is rather like possession of a binary executable image without the related source. Further, these files are often large compared to the amount of musical information conveyed; of these, PDF is the best in this regard.

In addition to the on-line distribution described above, there is considerable distribution of scores using the more prominent proprietary formats, such as those used by Noteworthy Finale and Sibelius.

Where used, a score fragment is prepared using one or another of the tools (Sibelius and Lilypond being most common among Wikipedians). The tool is used to generate a PNG file, which is uploaded to Wikipedia and embedded in the article.

The main problem with this is that it doesn't allow any collaborative editing of the score fragment. Another editor wishing to change the fragment must re-enter it using her tool of choice, export, upload, and embed. For the time being, editors using external Lilypond (or any other notation system with an ASCII representation) are encouraged to include their source at the image description page (for example: w:Image:Seikilos_score.png) as a stopgap solution. Since Lilypond notation is not entirely stable, including the version number of your Lilypond is also recommended. To deal with non-ASCII notation systems, such as Sibelius, editors could upload midi sources to accompany their images, but this may be overkill in many situations.

MIDI is believed to be patent free: devices that use MIDI in combination with some other technology can be patented. Documentary confirmation of the liberty for use of the MIDI standard would be reassuring.

Wikitex music will be magnitudes smaller in kb size than equivalent ogg files. But also will ask more of the server capacity to convert it to as both sound and image. Is it worth the deal?

I suggest mitigating this by having the conversion to .png and .midi done at the time of submitting an edit to an article, rather than each time the article is downloaded. This will still consume server resources, and was probably already evident to everyone, but I thought it should be mentioned.

LilyPond consumes very little time/memory for producing MIDI, at least if you compare it to the vast amounts of resources the program uses for typesetting.

Lilypond's ease of use may enhance greatly the new kinds of articles created on wikipedia (every musical article could have a music: template) are we ready for it?

Since Lilypond is the most prominent open-source engraving system, its use would seem a logical direction for Wikipedia. Proponents of Lilypond have suggested that it be incorporated into the Mediawiki software in a fashion similar to what has been done with TeX.

There are two problems with this:

Someone has to do the work.

Although Lilypond has a "safe" mode designed for CGI use, there is conjecture that it may not be sufficiently secure.

Lilypond would meet the project's needs in other regards, and would be a good fit technically because it already runs on many versions of Linux, utilizes a simple, command-line interface, and produces TeX, PNG, and MIDI output.

Han-Wen Nienhuys is one of the two major authors of Lilypond and has expressed support for the idea of using Lilypond at Wikipedia.

We would also very much like to move our glossary of musical terms to Wikipedia. Finally, please let us know about deficiencies of the "safe" mode. The safe mode has been revised for version 2.4 and I would welcome testing of LilyPond as a webserver application.
--Han-Wen

Another notation which might be ideal is ABC. This was originally designed for monophonic Western folk music, although it can be used to typeset pretty complex stuff. It's simpler to learn than Lilypond, and probably less taxing on the server. Given that most of the music required would generally be simple stuff, music theory examples, and so on, perhaps a full blown typesetting package isn't the only way. ABC can be rendered through TeX, or into PostScript, and indeed it's pretty simple to learn to read in text format.

Ideally, something like <music>a b c d</music> would give us a rendered version of the above; a nicely-sized PNG image clickable to a MIDI file.

The score, paper and midi sections (and notes?) would probably be provided by a wrapper appropriately tweaked for inline material. But would we need greater control? How would lyrics fit in? People who know music would be a help here. ;)

Lyrics could fit in as follows:

standard xml

(all elements): <key>a4</key><duration>24</duration><lyrics>Say ...

(with attributes): <notekey="a"octave="4"><lyrics>Say ...

a more concise and readable notation that would fit to the spirit of wiki notation

<notes>=<note>[<space><item>]..
<item>=<event>|<non_event><event>=<note>|<rest>// all events have a duration<non_event>=<barline>|<slur>|<marking>|<signature>|<roadsign><barline>="|"<slur>="u"<signature>=<clef>|<timesignature>|<keysignature><clef>="Gclef"|"Fclef"|"Cclef"<level><timesignature>=<number>"/"<number>"="<number>// the last number indicates how long a bar is (in elemetary time steps)<keysignature>=<number><simpleaccidental><marking>="crescendo"|"allegro"// (and so on)<roadsign>=<repeat_begin>|<repeat_end>|<da_capo>// (and so on)<note>=<pitch>","<duration>,<accent>[";"<lyric_syllable>]// (duration is in elemetary time steps)<pitch>=<letter>[<generalaccidental>]<octave><letter>="a"|"b"|"c"|"d"|"e"|"f"|"g"|"A"|"B"|"C"|"D"|"E"|"F"|"G"// upwards lowercase, downwards uppercase<simpleaccidental>="#"|"b"<generalaccidental>="#"|"b"|"o"|"x"|"bb"<octave>=""|"1"|"2"|"3";(and so on)