Music markup

From Meta, a Wikimedia project coordination wiki
Other languages:


Note: Content below may be outdated. The Score extension was deployed on 2013-04-22 and Bug 189 has been closed. Some example usage is at enwiki and the extension's own page.

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.

As TeX-based math markup is being implemented and automatic map generation is contemplated, it has been suggested that we also provide a handy way to include musical notation, such as via GNU Lilypond.

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.

GrafZahl solved this issue with the "Score" extension to MediaWiki.

Background[edit]

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Present State of Affairs at Wikipedia[edit]

Musical topics make, at best, sparse use of notation.

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.

The open possibilities of music markup in wikipedia[edit]

Possible advantages:

  • Excerpts of great pieces works in wikipedia articles
  • Anthems made easier in wikipedia articles
  • (we could even write a collaborative built official wikimedia anthem!!)
  • Classical music kept as original in wikisource with the following advantages:
    • no copyrights infringement for the actual phonogram, as no artist actually played or recorded the work
    • music can be edited for corrections, different versions etc
    • laypersons may add music with their basic primary school notions and experts can turn into a featured sheetmusic
    • ready for print to students, ready for hearing for anyone
  • wikibooks with lessons of music for music teachers
  • all easier and quicker to edit and contribute, in a true wikipedian way.
  • See also WikiScores

Open questions[edit]

  • 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?

discussions and answers here

Different technologies[edit]

Lilypond[edit]

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:

  1. Someone has to do the work.
  2. Although Lilypond has a "safe" mode designed for CGI use, there is conjecture that it may not be sufficiently secure.

Using Lilypond[edit]

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.

Here's a mindlessly simple Lilypond input file, using syntax for LilyPond 2.4.

 {
    a b c d
 }

When run through LilyPond, it produces a PostScript file with a rendered page.

It is also possible to produce MIDI files, but at present they leave out many expressive effects, making them unsuitable to demonstrate nuances of music (notation).

Basically, LilyPond is written as this

<music>
	\notes \relative c' { 
		e16-.->a(b gis)a-.->c(d b)c-.->e(f dis)e-.->a(b a)
		gis(b e)e,(gis b)b,(e gis)gis,(b e)e,(gis? b e)
	}
</music>

and outputs as this:


Edit or Play

Security[edit]

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

Short notice: This work is now done by Johannes Schindelin. See Lilypond-Patch from Johannes Schindelin for MediaWiki in Bugzilla at: http://bugzilla.wikimedia.org/show_bug.cgi?id=189 . Have fun. Arnomane 00:38, 12 Jan 2005 (UTC)

Tim Starling has said (September 26, 2008):

My understanding is that

a) safe mode is not secure, being trivially DoS-able by short infinite loop scripts
b) safe mode will not work for many of the free scores available on the web

The problems with LilyPond are sufficiently severe that I have, from time to time, researched alternative music renderers such as Philip's Music Writer that don't have an embedded scripting language.

For more information on this, see Bug 29630 (Make mw:Extension:LilyPond safe against DoS attacks).

Lilypond links[edit]

ABC Notation[edit]

en:User:Calum has proposed a variation on ABC notation:

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.

ABC Notation Formatting[edit]

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
  1. (all elements): <key>a4</key><duration>24</duration><lyrics>Say ...
  2. (with attributes): <note key="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)

Example:

Gclef 2# 4/4=16 a,2;The | d1,4;Rose c1,2;sum- b,2;mer's a,4;em- b,2;blem c1,1;'tis u d1,1

A Proposed Backend for ABC[edit]

There would be some implementation details in common with the TeX/math stuff; I'm considering setting up a more generalizable plugin/inline converter interface in the code. Basically:

  • note sections of magic code in <nowiki>, <pre>, <math>, and <music> blocks
  • take the chunks out and perform any necessary conversion, roughly:
    • for fancy things like math and music, check a hash against a table of known already-rendered items
      • if not already rendered, shell out to the rendering program and if ok note in the table
      • provide image or alternate representation(s)

Apply the patch on the Talk:Music_markup page to add ABC support.

Other proposed and experimental implementations[edit]

A wikitech post by Peter Danenberg has information on an interesting TeX markup scheme (which includes Lilypond). More detail is available from mailarchive:wikitech-l/2003-December/007300.html

See also[edit]

External links[edit]