Slashdot Mirror
MusicXML DTD Hits 1.0; Browser Support Next?
base_chakra writes "Two years since its initial release, the MusicXML music notation document type has finally reached v1.0. MusicXML is an (you guessed it) XML-based musical score format developed by Recordare LLC, and derived from the MuseData and Humdrum projects. Although MusicXML was quickly adopted by virtually every major music notation software products available, a standard non-binary format for rendering music notation on the web is something that's still sorely needed. Despite its unfortunate limitations, will MusicXML eventually become the de facto means of rendering music notation online, or will it fall into obscurity like so many document types?"
"XML-based musical score format developed by Recordare LLC," how could i have guessed that?
I guess it's time to read up on XML and learn what all this hoopla is about! <g>
---
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
If the format is open and free, then it has a good chance of becoming widespread. Otherwise, no.
Thanks for asking.
That's "Mr. Soulless Automaton" to you, Bub.
"Seriously. Does anyone believe "standards" created by companies?"
Yeah, those at Microsoft do.
Evolution or ID?
We still can't get good SVG support in a browser (unless you have IE on window/mac and Adobe's plugin installed). I can't imagine supporting MusicXML in the browser before SVG... besides, once SVG is supported, XSLT should be able to transform MusicXML to SVG, SVG Print, or PDF.
The project seems dead or near death right now, but it would have been a great tool for teaching music in schools. Especially if it turned out like Guitar Pro.
Guitar pro is not free and uses a proprietory file format. But it is an excellent way to learn guitar by "playing along" with the pros.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
There already is a fairly widespread musical notation format in use on the web. It's called ABC. There's even a Sourceforge site for it.
That said, ABC isn't perfect - it's evolved in many ambiguous and incompatible ways over the years, making it difficult to code a common parser. MusicXML might be better suited for that job, or for professional use.
For casual use, though, ABC is tough to beat.
I don't know what kind of audience would really care about music notation, but I know there are a bunch of us guitar-wanna-bes who frequent good ol' ASCII-art notation sites for our favorite songs, which are obviously lacking in detail. And word can spread quickly if people are notating using this format and recommending a proper browser to view them with.
Here's hoping...
Read the FAQ linked above: "Before MusicXML, the only music interchange format commonly supported was MIDI. MIDI is a wonderful format for performance applications like sequencers, but it is not so wonderful for other applications like music notation. MIDI does not know the difference between an F-sharp and a G-flat; it does not represent stem direction, beams, repeats, slurs, measures, and many other aspects of notation." For musicians, this is a big deal
I think they are being very reasonable with their licensing structures.
1: The Format is fee-free provided you follow the license
2: The software is not free/OS. SO? Not everything should be free. I am ALL about OO.o and Linux, and whatnot, but trying to claim that all software should be free is just stupid, and giving list "unfortunate limitations" jab is unfair.
Would you prefer the XML format they designed to be GPLed? Wouldn't that make it useless? Everyone could modify the format and then you wouldn't have a standard format?
-lv
p.s. Here come the GPL flames. Bring it on!!!!
If you are out to describe the truth, leave elegance to the tailor - Albert Einstein
There is a clear need for a better way to share music notation. At wikipedia, there has never been a consensus so TeX generated by Lilypond or something similar is used. That works poorly, because it is hard to integrate with CGI, and without integration only users who have Lilypond themselves can contribute.
Same set of problems at composerplanet.com, though they are still getting their site together and haven't chosen a strategy. Looks like .PNG and .JPG images will be the de facto standard. Ick.
Lilypond is free, and runs on Linux, but is unlikely to become much of an interchange standard because the UI isn't accessible to the vast majority of musicians, who are as a rule not experts on writing something according to a context-free grammar. Besides, Lilypond is best for typesetting-quality layout, at which it does indeed excel.
Whatever the solution becomes, the ability to share scores with ease will touch off another wave of handwringing among sheet music publishers. I just yesterday received a book with all of Scott Joplin's piano music in it -- all written before 1915 -- and guess what? It says right on the front page that it is against the law to copy them! So far, most musicians don't know any better, but if MusicXML comes to pass, that may all change.
This format is for music notation, which can contain many things that either are not contained in a control-based format (conductor-discretion items such as holds) or are not easily gleaned from context (crescendoes, block repeats, etc...).
From the faq...
In short MIDI knows nothing about music notation. It can not render the music score that it is playing for you, on your computer screen. There full answer is in the FAQ. I suggest reading that.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Rendering music in a browser......
RIAA Lawsuit in three, two, one.....
-
Tech News, Reviews and Tutorials
It makes files so absolutely huge. Even something like "A" is a least 14 bytes, whereas in a binary format, it would probably be 2 at most (identifier byte and note byte).
Binary formats, while harder to design for extendibility when using this sort of data, are a lot more compact.
MIDI, MOD and like are good for storing events. In other words, they're excellent formats for storing music data intended to be interpreted and played back by computer.
However, they're very bad formats for storing notation, musical information that is intended to be human-readable. It's enough for computers to know "Pause of 0.3 seconds; C-4 note duration 0.6 seconds", but human performers have problems deciphering such notes. And as everyone who has messed around with conversion tools, MIDI-to-notation tools are inferior compared to hand-tweaked notation.
As for "bloat" of storing music in text formats, you can store a single note in GNU Lilypond in three bytes (or, in optimal cases, two, or one); can your MIDI or MOD files do the same? =)
Nay, Lilypond is the true king of open notation formats, even if it isn't XML-based and otherwise buzzword-compliant =)
I read both of those links.
As far as I can tell, the MusicXML license is just a BSD license. Give credit where it's due for the DTD and you can use it wherever you'd like. I really don't see the limitation there...
Just because it's not GPL doesn't mean it's useless.
I've been working on LilyPond for the past eight years, and we're now finally reaching a stage where the output can be taken seriously. I estimate that it took over 4 man-years of work to develop the current source code (60k lines of C++, 10k Scheme, and 10k python). Of all that source, less than 10 % is concerned with the file format, and they form the easy bits. When it comes to notation, file formats are not the problem.
If you want to read more in-depth information on notation vs. music representation , I recommend to read the essay at lilypond.org.
Regarding buzzword compliancy: have a look at our XML format, but like I said: the format is besides the point. Han-Wen (LilyPond author)
Han-Wen Nienhuys -- LilyPond
MusicXML does not really go past very basic score representations. Most modern (i.e. > 20th century) notations are not possible. Its like saving a complex MS word document in .txt format, its mostly useless.
Mozilla does not support XML for musicians
Status Whiteboard: BLOCKED: needs a spec, a comprehensive test suite, and a reason to implement it
Well, we have a spec now at least. Unfortunately, this bug is dependent on bug 39965 (Layout should permit pluggable support for new frame types), which is currently not assigned to any developer.
It'd be nice to be able to read and print a high fidelity score. The best I've seen so far are PDFs and TEFs (which I think are proprietary). Yahoo for standards.
Take a good look at the format. Its a spec defining how to digitize musical scores. When was the last time you went looking online for the score of a particular website? Whe was the last time you went looking online for a score that you could legally download?
This is an important protocol - for all those projects out there digitizing old music scores. Think classical music like Beethoven/Mozart. Up until recently, everyone in this buisness made their own homegrown system. Just to give a taste of where this project comes from:
These are just the standards I know of. This site lits many more I've never heard of. Hopefully MusicXML obsoletes these countless competing standards so those who research in this field can finally exchange data with one another - without porting around and maintating a collection of converters.
However, this really is irrelevant for the vast majority of slashdot readers. Unless your trying to digitize musical transcriptions, this standard is a curiosity at best. I have to wonder why it made the slashdot front page.
The number you have dialed is imaginary, please rotate your phone 90 degrees and try again.
You wouldn't use a font. Many Music fonts (and math fonts) draw the same character once in each position; each in it's own glyph. With SVG, you simply draw a note:
/> />
<g name="wholeNote">
<circle cx="0" cy="0" r="40" class="wholeNote"/>
</g>
And draw that same note as many times as needed. No need to make a separate glyph for C and D note:
<use xlink:href="#wholeNote" x="580" y="450"
<use xlink:href="#wholeNote" x="560" y="490"
Space may be an issue, but MusicXML isn't exactly light-weight. An SVG conversion might even be a bit smaller than the original file. Either way, a full composition would be a huge download (even in its original MusicXML format).
The real problems with an SVG or PDF implementation would be details like wrapping lines. I also question, in retrospect, if XSLT would be too much of a pain in the ass. Maybe a Ruby script would do a better job.
Here is some gregorian chant, or polymetric stuff.
nonstandard key signatures,
See this example
cutout scores, feathered beaming, ossia measures, etc.
These are not supported, although feathered beaming would not be difficult to implement. However, I have played in a ensemble that plays 20th and 21st century music exclusively for the past five years, and I have rarely seen the contraptions that you mention in modern music; most of it is notated with traditional notation, with a lot of time-sig changes. In fact, publishers nowadays will not engrave such funky scores, but have them written by hand, or they will reproduce the manuscript (Unless you happen to be called Xenakis or Berio.)
I had a copy job that I originally tried to do in Lilypond via the text interface and copying one part from the score took almot nine hours of typing, rendering it, fixing it, and re-rendering it to ensure that it came out right.
YMMV; I have recently produced parts & score (4 pages for the 2nd part). It took me approximately 30 minutes. Granted, it was a straightforward piece, but the speed depends much on how well-versed you are with the software. Finally, LilyPond has progressed very much in usability over the last year. If the last time you tried it was more than a year ago, you might want to give it another go.
Lilypond would need to have a nicer MIDI-compatible interface thrown on top of it to compete.
Have you seen RoseGarden and NoteEdit.
Han-Wen Nienhuys -- LilyPond
It will do for music what CSS & XHTML with metatags do for printed text...Right now sheet music is still the standard for music notation...it's not couducive to archiving or sharing [sans simply scanning the paper copy] Imagine having the musical equivelant of Google where you can find a song by just a few notes...MusicXML allows you to develop that!
Once those tools are set we can take on plays, speech, and eventually source code too! This is one of the first really original uses of XML...what it was created to do!
I will add my voice to the chorus - MIDI is it and this is a solution in search of problem that it will not find. As for the problem of MIDI not being able to record a live performance and produce sheet music - who cares? After working with MIDI for over ten years, the only problem is that it cannot keep up with the nances of a great electric guitarist (SUPRISE - it was a keyboard language!) and only 16 programs and 128 voices. Both can be solved with an upgrade.
But none of this really matters to web pages! The latest Quicktime synth is awesome if programmer correctly but like most MIDI synths these days, it is in desparate need of some nice expressive electric guitar sounds. Let the engineering go where it is needed, PLEASE!!
And hey - whatever happened to MPEG-7 Structure Audio anyway???
Well, MIDI is nice, but it's just instructions for an instrument. MusicML is desireable because the other formats are either proprietary (and tied to particular composition/editing program like VST), or are weak like MIDI or scanning-handwritten-pages.
MIDI is bad because it doesn't really tell you anything about how the notation should appear. You could write a pretty smart interpreter that would produce some readable score, but the author loses a lot of control.
Scanned Scores suck, because they're generally pretty large, may not print cleanly, etc. Also, good luck writing an application that will do the musical equivalent of OCR and get you something you can play back on a digital instrument.
MusicML should be trivial to convert to MIDI for having a digital robot (PC+MIDI capable instrument) play, and also easy to convert to a score for an organic robot (Musician) to play.
You don't need to learn anything. Just use your composition GUI/environemnt of choice (Cubase, Digital PErformer, whater) to put together the score, and then save in MusicXML. Now everyone who has an application that can read the format can use it.
So it actually sounds pretty nice, based on my cursory look at it.
Well, time to whip out the plastic and buy yet another book for another standard that is going to be used... one day.
-Kids in the back seat causes accidents.- -Accidents in the back seat causes kids.-
Er... anyone who wants to produce sheet music?
Seriously, what was your point? We're discussing a music notation document type here - RTFA. And manuscript is the standard way to notate music, one that goes back hundreds of years, and that hundreds of thousands of people use right now. MIDI is a (very good) solution to a completely different problem, that of controlling synthesisers - it's been extended into other forms of performance and sequencing, but it's completely unsuited to music notation: see my other comment here for why.
Ceterum censeo subscriptionem esse delendam.
The other thing I would do would be to give the files that I used to create the music. In my case, it's Finale. But, I have YET to do that. I like to retain some sort of credits for doing the work. PDF allows me to do that. And if they want to hear it, creating an MP3 of a score is simple as well.
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
"WEFSAFD" was random frustrated keyboard mashings.
You say "Computer readability" then you mention an example of someone opening the file and looking at it.
As an API developer I would care what the physical structure of a file is only because I'm writing functions to write to these files. As an application developer I couldn't care less; I would be working with high-level things like 'measures' and 'notes'.
The method of storage has absolutely nothing to do with it being proprietary or not. In this case, XML is both ASCII and open, in that it doesn't obfuscate the plaintext. I could easily create a non-ASCII but open (all you have to do is tell someone what it is) format, just as easily as I could create an ASCII but 'closed' format (encrypting your message to an ASCII format for example).
Further, the scenario you paint makes no sense. A computer program does not need a file to be in ASCII text to be able to understand the structure and therefore derive meaning.
The only thing remotely plausible is that someone would look at the file contents but what is not plausible is that, given a super-duper-recognizing browser, they would use a text editor and not the penultimate file browser.
Thanks,
--
Matt