MusicXML DTD Hits 1.0; Browser Support Next? 238
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?"
you guessed it? (Score:2, Funny)
Re:you guessed it? (Score:3, Funny)
Steps to guessing:
1. Focus on the XML-based musical score format half of the sentence, rather that the developed by Recordare LLC portion.
2. Realize the name of the format is MusicXML
3. Guess
Now, that is not to hard, is it?
Re:you guessed it? (Score:2)
Great! (Score:5, Funny)
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.
Re:Great! (Score:5, Funny)
Write this: I guess it's time to read up on XML and learn what all this hoopla is about! <g>
Like this: I guess it's time to read up on XML and learn waht all this hoopla is about! <g
Re:Great! (Score:4, Funny)
Re:Great! (Score:2)
Easy answer (Score:3, Insightful)
Thanks for asking.
Re:Easy answer (Score:2, Informative)
Is MusicXML free?
The MusicXML DTD is available under a royalty-free license from Recordare. This license is modeled on those from the World Wide Web Consortium (W3C). If you follow the terms of the license, you do not need to pay anyone to use MusicXML in your products or research
****
In theory, I suppose, you could try to make an XML DTD propriatary, if you wanted go around suing anyone with a pair of eyes (it isn't a file format, it's a Document Type Defintion. A human readable text file
Re:Easy answer (Score:4, Insightful)
Examples of widespread file formats:
I'm sorry to say, but marketing seems to have a much more profound effect on the spread of a file format than its openness and freedom.
Re:Easy answer (Score:4, Insightful)
From the AC:
HTML I'll give you as a well-supported open standard file format. PDF, not as much, but better supported than the MS formats.
I suppose for balance, supported documented file formats would include:
And, for further comparison, well documented open formats that somehow just don't seem to be as widespread as you might hope:
A blanket statement really can't cover all the possibilities. It just seems that despite the advantages to open formats, the market just doesn't seem to care right now.
Re:Easy answer (Score:2)
SVG First (Score:4, Insightful)
one problem, music fonts (Score:2)
Where is it going to get all those funny obscure fonts that music notation uses?
Saying just use XSLT to convert MusicXML to SVG, I think is like saying just use XSLT to convert MathML to SVG. You are going to have to draw every obscure symbol the Music or Math notation needs and your resulting SVG document would be impractical in size.
Nop, I don't think that would work very well.
Re:one problem, music fonts (Score:2)
Re:one problem, music fonts (Score:3, Interesting)
<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 ex
Re:EEEEWW!!! (Score:2)
In fact, there are tools for converting true type fonts to svg [apache.org]. The W3C has information on how to use these svg fonts [w3.org].
Re:one problem, music fonts (Score:2)
I think you miss what XML formats were designed for. They designed XML to be flexible enough to represent high level concepts [like music
lets give XEMO a hand (Score:4, Informative)
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.com].
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.
Re:lets give XEMO a hand (Score:3, Informative)
What about ABC? (Score:5, Interesting)
There already is a fairly widespread musical notation format in use on the web. It's called ABC [gre.ac.uk]. There's even a Sourceforge [sourceforge.net] 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.
Re:What about ABC? (Score:2)
Ohh, and the parsers are content agnostic. Music, accounting data, children's stories, whatever. Same parsers.
Re:What about ABC? (Score:2)
Notice anything about that? Well, probably not, if you're not a musician. But any musician should be able to spot that for monotonic music, ABC is damned easy to read. I've no idea what MusicXML looks like, but I don
A good thing for Mozilla? (Score:3, Interesting)
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...
Re:A good thing for Mozilla? (Score:5, Funny)
Re:A good thing for Mozilla? (Score:2)
Unfortunate Limitations (Score:2, Insightful)
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
Re:Unfortunate Limitations (Score:2)
Re:Unfortunate Limitations (Score:2)
Sounds like the Adobe business model. The Acrobat reader is free for the asking. If you want to create a bunch of Acrobat files using anti-copy features or E-reader format, well then you have to pay the piper.
Re:Unfortunate Limitations (Score:5, Insightful)
Or is there some kind of zealots' vendetta going on, of which I was not previously aware?
Lilypond (Score:2)
So it looks like now I could take Finale-produced XML output, run it through xml2ly and get my Lilypond sheet music. Has anyone tried it?
Re:Lilypond (Score:2)
Hoping for the best (Score:4, Interesting)
There is a clear need for a better way to share music notation. At wikipedia [wikipedia.org], 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 [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.
Re:Hoping for the best (Score:5, Informative)
They have been at it a while converting old editions and manuscripts. Help 'em out if ya can!
They've currently got 387 pieces of music going, and they're adding more and more quicker and quicker.
Re:Hoping for the best (Score:2, Interesting)
I'm not a musician, but I'm definitely a printer (or that's my heart's calling, or some other lame explanation like that). From my point of view, Lilypond rules. It's so
Typesetting isn't original enough (Score:2)
Nothing you read on Slashdot is legal advice.
it has probably been tweaked in some way so that copying it is, in fact, not legal. If it has been newly typeset, edited, annotated, etc, that is all fair game for copyright even if the music itself is in the public domain.
A publisher's typesetting and annotation would affect only the right to reproduce the work through photocopying or to reproduce the annotations. Transcribing the notation from a public domain song in a copyrighted compilation does not in
Lillypond (Score:2)
Re:Lillypond (Score:5, Interesting)
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 [lilypond.org].
Regarding buzzword compliancy: have a look at our XML format [lilypond.org], but like I said: the format is besides the point. Han-Wen (LilyPond author)
The trouble with XML (Score:2, Insightful)
Binary formats, while harder to design for extendibility when using this sort of data, are a lot more compact.
Re:The trouble with XML (Score:3, Interesting)
In addition, breaking some of the information out of *this* spec into another namespace (like all of the MIDI-related stuff), as well as using existing namespaces like RDF for meta-data, would go far into simplifying some of this.
Ma
.xml.gz; problem solved (Score:2)
Just do what OpenOffice did, and ZIP the thing. XML is text, meaning that zipping it up will leave you with a file that may even be smaller than a compareable binary format. Or so I've heard with the OO.o format versus latter .DOC format debates.
Plus with this approach you can write a simple script to pull information from your XML f
The trouble with XML (Score:2)
If you look at the FAQ they note (and I quote) :
"The two-page Schubert song on our web site takes up 223K in its uncompressed form, but compresses to only 8K using WinZip. This is even smaller than the MIDI representation, which is 9K, and the XML contains much more data about the music."
Binary formats are nice for speed, but a serious pain to use/document/extend. XML is far easier to extend, there is a growing and powerful toolset available to deal
Make a simpler format for human (Score:2)
Well, maybe it's not that obscure, but... (Score:2)
pcx is hardcore
Browsers? Why over PDF? (Score:2)
I do my scores [tringali.org] in PDF, if I want people to be able to read and print them. Yeah, the PDF is a bit ugly on screen because of Finale's strange linestroke style, but it prints out just fine. I also use ps2pdf.com, the scores do look much better with Acrobat.
(
Re:Browsers? Why over PDF? (Score:2)
Some people want their data stored in an open, free data format that is not locked into just one software program or another. They don't want a MUS or FTF or whatever because 10 years from now, their program might not know what that is. XML will be readable for decades to come.
Ideally, a commercial score-writing software program could store your data in MusicXML and output, if necess
Re:Browsers? Why over PDF? (Score:2)
Re:Browsers? Why over PDF? (Score:3, Insightful)
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,
Re:Browsers? Why over PDF? (Score:2)
Good PDF scores use font embedding. Since the truetype fonts are embedded, they remain very small. Take a look at the ones on my website for an example. The PDFs are astoundingly small -- about the size of the corresponsing corresponding .ETF file, which is ASCII-encoded, just like an XML data file would be! And that's just with ps2pdf.com -- Acrobat does even better.
Example: on my site, Moanin' in (the program's own) ETF format is 305K. The PDF is 299K. If you look at the innards of the ET
Unfortunate limitations...?! (Score:3, Insightful)
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.
Re:Unfortunate limitations...?! (Score:2)
Personally, I'm not going to try to make a second viewer/editor for a format that I can't even see in a pre-existing viewer.
Re:Unfortunate limitations...?! (Score:2)
Open Source is not always the right solution.
Re:Unfortunate limitations...?! (Score:2)
Re:Unfortunate limitations...?! (Score:2)
Re:Unfortunate limitations...?! (Score:2)
not all its cracked up to be... (Score:2, Interesting)
Re:not all its cracked up to be... (Score:2)
I only ask because I'm curious.
Re:not all its cracked up to be... (Score:2, Informative)
Based on what I see from Lilypond's introduction, it isn't capable of producing print music that doesn't conform to that definition of "music" we're so used to. For example, mus
Engraving with LilyPond (Score:3, Informative)
Here is some gregorian chant [lilypond.org], or polymetric stuff [lilypond.org].
nonstandard key signatures,
See this example [lilypond.org]
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 [studver.uu.nl]
Re:not all its cracked up to be... (Score:4, Interesting)
But then you're stuck with Finale's output, which is mind-numbingly uniform and, thus, vastly more difficult to read in performance than Lilypond's more beautiful output. Yes, true. I'm not talking about in pop stuff or other simple music, but in music that is complex enough so that it must be read in performance. John Cage, one of your examples, created music that is inherently difficult to memorize; it is unpredictable enough that it cannot be reduced to pattern or algorithm. (Generally, Crumb and Schwantner, two more of your examples, are not difficult to memorize.) Since there may well be more reading going on in complex music than in simple music, in complex music, like Cage's music, the quality of the score become very important.
Music engraved by experts is better than Finale output because it is easier to read. Well-engraved music provides all sort of visual cues to help a performer play the correct notes in the correct rhythm, keep his or her place on the page, etc. A sort of visual grammar has evolved over centuries of engraving, and even nexperienced musicians respond to it with hardly a thought.
The Lilypond programmers seem to have done remarkable work in parsing this grammar and deriving rules, then using the grammar to improve score output. Finale and Lilypond are night and day in terms of ease in reading.
I am a musician who performs a lot music of the last fifty years--Crumb, Cage, and Schwanter, among many others. I have used Finale regularly since 1989. I tried Lilypond a year ago, and I won't be going back.
Re:not all its cracked up to be... (Score:2)
(Okay, we'd want to keep jazz, but you can't really notate that music anyway.)
Mozilla Support (Score:3, Interesting)
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'll make the 'black page' easier to write.. (Score:2)
One of the exercises was to listen to some African drum music and write it down in notation.
I bombed completely, but the dedicated music students wound up producing something reminiscent of Frank Zappa's 'black page drum solo'. It wasn't the 'easy, teenage, New York version' either.
There are some forms of music that simply cannot be expressed in western music notation and I found that intensive training in this
designed for research/librarians - not the public (Score:4, Informative)
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 [acadiau.ca] 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.
MOD PARENT UP. (Score:2)
The true value of MusicXML is as a universally understood format for describing musical scores digitally. The music libraries of the future aren't going to be made of paper, don't you think?
Oh really... (Score:2, Flamebait)
Really? I'm a composer and performer and I have never felt the lack... This is an advantage for me how?
Where is this perceived need to render music notation on the web coming from?
Ultimately, a waste of time. I'm not going to laboriously code up my music into MusicXML format, that's completely insane:
Is it easier than writing out the music, scanning and posting the scan? Not if I
Re:Oh really... (Score:3, Insightful)
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 gene
MIDI file limitations (Score:2)
And you ain't just whistlin' Dix... Er, yes, indeed.
To be more specific: MIDI doesn't tell you what clefs and key signature(s) to use. It can't hold slurs or phrasing, accents, articulations, breath marks, or other note symbols. It has no way to represent repeat marks, first/second/third-time bars, 'da capo', 'dal segno', or 'coda' directions. It can't control note grouping or splitting, stem direction, use o
Re:Oh really... (Score:2)
Like traditional music notation does? Do we really need to invent a markup language to represent a markup language? It obviously does not introduce anything new that traditional notation does not. If you have learned, like most musicians, how to read traditional notation, where is the advantage to using MusicXML?
Think for a second. Why create an new markup language to overlay on
I agree - MIDI is it! (Score:3, Interesting)
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???
Midi can record live XML- Midi (Score:2)
Also some of the expensive audio programs do midi to sheet music. logic pro [apple.com] does it (see the sidebar on the right..) and I'm sure there is more.
Re:Midi can record live XML- Midi (Score:2)
And yes, there are MIDI guitars *but* if you faithfully try to all of the nances of say, a Jimmy Page guitar solo, all the pitch bend message messages will flood the sequencer. I have tried this in *ages* (I don't actually own a MIDI guitar) but even if the recorder will keep it, it has got to be a BEAR to
No, MIDI solves a completely different problem (Score:3, Informative)
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
And yet, another thing to buy a book for. (Score:2, Funny)
As a musician.... (Score:3, Insightful)
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 [finalemusic.com]. 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.
Re:Two years from now... the patent surprise! (Score:3, Funny)
Yeah, those at Microsoft do.
Re:What about MIDI/MOD/XM/etc? (Score:5, Informative)
Re:What about MIDI/MOD/XM/etc? (Score:2)
I do most of my work in a sequencer (Digital Performer [motu.com]), and then dump the Midi file into Finale [finalemusic.com] to make it look nice.
I think what is REALLY needed is some sort of OPEN FORMAT to save music files into. Perhaps this will bridge the gap. So, if I want to give a file to someone with Sibelius, they can open it. Make changes
Re:What about MIDI/MOD/XM/etc? (Score:2)
Re:What about MIDI/MOD/XM/etc? (Score:3, Informative)
Re:What about MIDI/MOD/XM/etc? (Score:2)
Plus writing tools to manipulate XML vs. a Binary format is much easier.
Re:What about MIDI/MOD/XM/etc? (Score:2)
read the FAQ (Score:4, Informative)
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.
Re:What about MIDI/MOD/XM/etc? (Score:3, Informative)
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 t
Re:What about MIDI/MOD/XM/etc? (Score:2)
This is listed on their FAQ page as one of the programs supporting MusicXML. Sure, it's only one way at the moment (convert musicXML to Lilypond) but I'm sure that can change.
Re:What about MIDI/MOD/XM/etc? (Score:2)
First of all, the binary formats do do the job. Look where MIDI for example is typically used. MIDI in the music world is generally two (or more) devices communicating to each other. That the devices in question are not high powered computing machines also militates against a textual format, as it is inefficient compared to the binary transmission format. The readability of the format is moot, since generally one device in the chain is capable of interpreting MIDI sequences in
Re:What about MIDI/MOD/XM/etc? (Score:2)
Really? I find it much easier to read "poco a poco decrescendo" than to read "play note at volume 120 play not at volume 110 play note at volume 100 play note at volume 90 play note at volume 80 play note at volume 70 play note at volume play note at volume 60 play note at volume 50 play note at volume 40".
I even find it easier to read "con sordino" than "switch to patch 52"
Obviously you know nothing of music. Would you let a football player redesign yo
Re:What about MIDI/MOD/XM/etc? (Score:2)
I don't however, see a need to let a programmer redesign how I write music. The old fashioned staff works well enough for me. The fact that literally thousands of devices and programs exist which present me the staff I know and are comfortable with, but generate MIDI binary format make learning an
Re:What about MIDI/MOD/XM/etc? (Score:4, Interesting)
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!
Re:What about MIDI/MOD/XM/etc? (Score:2)
I've read the other posts.
No one yet has given me a reason to think that writing music in this markup language is any better than writing music in its original markup language. That I think is the bigger point. Music has been written on the staff for hundreds of years. In computer speak, it is a robust, well designed language if you will. It satisfies the requirements, is completely human readable in and of its own, is portable, bottom line traditional music notation has all the hal
Re:What about MIDI/MOD/XM/etc? (Score:2)
MOD is to music what a jigsaw puzzle is to painting.
Re:MathML too (Score:2)
Mozilla supports [mozilla.org] MathML pretty good, and the fact that only geeks would be interested in math docs, and they usually use Mozilla, this fact made me use it along with TeX.
Good for everyone (Score:3)
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.
That's the point (Score:2)
Re:Eww! More web page background music! (Score:2, Funny)
RIAA Lawsuit in three, two, one.....
-
ASCAP (Score:2)
Having been in band in school, sheet music licenses are actually worse that the EULAs written by demon MS lawyers...You can't actually BUY sheet music of arranged pieces...you have to RENT it PER PERFORMANCE! OUCH!
Re:Standards.... (Score:2)
Re:MusicXML code is bloated, useless (Score:2)
"Why?"
And it turns out there's really no good answer other than just taking a ride on the buzz train.
On the other hand there are a ton of reasons why XML stinks to high heaven as a musical notation format.
You'll find a short but humorous look here:
Music XML [dbdebunk.com]
Now here's an example of a plain text encoded note that I just semi made up on the spot:
g"4
Human readable. Machine interpretable. And musician readable. A vio
Re:Doh... (Score:2)
Particularly because Recipes are part data/ingredient manifest and part process order, mixing steps and settings. Solving a seemingly simple problem like this would have huge industrial applications as well!
Setting up such a system would require a most basic representation of the steps...because you can't try to assume every ingredient or tool necessary in the DTD, you'd have to have a way to represent the recipes without actually knowing [as the format creator] what was was actually in them.
Where are my moderator points when I need 'em? (Score:2)
-DA