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 never heard of this before. Really cool. I also like MathML as an XML format, too bad its support isn't great all over.
Seriously. Does anyone believe "standards" created by companies?
I'd just like to be able to read guitar tab files from guitar sites..
y songbook.com/
http://www.guitartabs.cc/home.php
http://www.m
http://www.guitaretab.com/
I found KGuitar, but it's pretty early.. I'd like a Gnome app but I can't find anything decent. Any ideas?
-Mitti
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.
Not only MIDI and MOD are free, open formats, so do the tools that make and play them! Why bother for another format, when binary ones are doing the job greatly? Besides, storing music in text formats are too bloated to be useful anyway.
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.
I guess that means my phpRecipeML program is going on the back burner. :-(
-Rob
Marriage doesn't have to suck!
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.
Why are they putting support for this in the browser? For web page background music and advertising jingles?
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...
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
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?
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.
And what was wrong with Lilypond's format? I know it's not that pretty but it works and is unencumbered. Was it because it wasn't buzzword compliant?
Prevent email address forgery. Publish SPF records for y
XMFdoes everything MusicXML does, and the files are much smaller! Why should I bother with such inefficient file format for an already solved problem? Adding 10 times the code for playing music within browser is absurd.
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.
will it fall into obscurity like so many document types?
pcx is hardcore
How the hell is this a troll? This question must unfortunately be asked about ANY supposed standard now. How many times have we seen someone attempt to patent some sort of standard that had been presumably open? In this case, I could more realistically see some record company trying to patent this as opposed to Microsoft.
MIDI
Whlie it's nice to have XML-based information transfer, sometimes it isn't really the best and is incredibly big for what it does. For live music playing, the simplicity of MIDI is a much better substitute for transcribing music into a 'non-binary' format.
Oh, it works with lots of electronic musical devices too - er... most of them in fact!
I do my scores 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.
(Note all of my more complex scores are not on the web. I usually only print out copies for those I give out or sell to, and rarely send out the electronic masters. People might photocopy my scores, but I'm sure not going to make it any easier for them.)
Now, if someone wants to play back the score, or edit it, then they need the actual .MUS (or .ETF) file from Finale. The only time I've ever needed this when collaborating on a score with a friend over email. It's really difficult because there's no way to merge changes or diff them.
Saving to this format would be handy, because I've been compelled to upgrade a few times when working with someone who has a newer version of Finale than I do. Unlike Word, my friend cannot simply say "Save As..." and select an older file version!
But unless they retrofit it into older versions of Finale, oh well...
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
If you want to see some cool ML take a look at the MPEG-7 specs ( and the accompanying reference implementation). You will never feel the same for any ML'ed joint effort to depict accurately "reality" :)
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.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Various packages such as Cubase etc. transcribe MIDI data into notated music.
What I'm basically saying is; MIDI's been around since 1982, contains all the required parameters, so why not just do a MIDIML and have done with it?
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.
Go to the site and check it out.
Here is a description:
MusicScript is an open-source music scripting language for linux. It is capable of creating complete songs from a script, using drum machines, synthesizers, samplers, and many effects. MusicScript was created by David Piott as an alternative to the limits of real-time music programs. With MusicScript, there can be an infinite amout of loops, tracks, samples, effects, etc. You create the song as a script file, which MusicScript will interpret and turn into a wav file Its a very basic program but it gets the job done and is very easy to learn. We also got this to compile in fink and work perfectly in OSX. So now we use it in Linux and OSX
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.
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 format, or debug your file format with a text editor, etc, etc...
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Lets not forget MIDI and other non-proprietary formats. There are many free utilities/applications using these formats. Do we really need yet another 'standard' "standards: everyone should have their own" to confuse matters?
PDF is a poor answer for scores. In many cases, the PDF files become unnecessarily and unworkably large even for simple scores. As a rule, they do not scale well. They cannot be edited and reposted, and are therefore useless on a wiki or any other collaborative forum. In many cases, I find that PDF scores require fonts or printer capabilities that my laser printer does not have.
Drawing them from a description stored in the same document isnt really a problem ... so what if you add a couple 10's of kb of data.
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.
nah, lemonparty.org is more like it.
Don't just think about inate browser support... I know that flash is a dirty word, but musicXML + flash + hardcore programming could potentially mean a neat application that would allow people to browse sheet music online and print good reproductions. Don't condemn it just for being verbose...
You buffoons! That's Grade A material!
unless this is a system to describe midi music I cant see this working. Music is too diverse to be usable in a markup language, the language would have to be huge. Music is its own very complex language and trying to express it in an overly simplistic markup language is about as worthwhile a project as writing a filter that converts all gifs on a web page to ascii art!! All this means is that Im going to have to listen to a million more web sites with useless and annoying music on them.
Ah, but the RIAA has no jurisdiction over printed music. :)
Someone would have to found an MPAA, which would get confusing as all hell.
KFG
It does use XML to represent music, and it is in MIT licence.
Seriously, people, READ.
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.
Printed music yes, but I was referring to the parents post about the XML being rendered into audible music by the browser. Although, I wasn't being too serious. :^)
Tech News, Reviews and Tutorials
MusicXML is a format that describes information relevant to musical notation, such as notes, slurs, articulations, clefs, and so on, and describes how those things should be drawn on a screen or page. MIDI, on the other hand, is a format that describes information relevant to music performance, like note number, note on, note off, patch change, and so on. Two very different things.
/
An alternative to MusicXML, for those interested, is Guido:
http://www.informatik.tu-darmstadt.de/AFS/GUIDO
I did ethnomusicology for a couple of years. I shared the class with final year music students.
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 format actually reduced people ability to comprehend non-classical-western derived music.
Oh and those final year music students frequently seemed on the verge of nausea when listening to certain asian or native american music.
In the free world the media isn't government run; the government is media run.
As they are mentioning in their own FAQ, the big challenge isn't really the format, it is the difficulty of displaying music and making a good GUI for modifying and creating notes and notation.
.mus-files (from Finale) are pretty much the standard used since Finale is the most popular of the two (also, Sibelius actually supports .mus-files).
There is only two programs today that can do this in a good enough fashion (good enough to get musicians to use it), Finale and Sibelius. Today
An open notation-format isn't going to change this (lilypond for instance has been around awhile and hasn't changed anything). It is the tools that will decide which format will be used so if you wan't an open alternative to commercial Finale or Sibelius then you have to write software that is better at the things Finale and Sibelius do.
MusicXML won't make a difference and my guess is that it will soon be forgotten.
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.
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 allready can read and write music... In fact, I'm incurring the overhead of learning an additional language on top of msucial notation in oder to do this. Most songwriters can learn to operate a scanner and a paint program in an hour, how long to reach that level of expressiveness in MusicXML? I suggest the learning probably never really stops...
Oh, I see, there is a program I can use to graphically handle the creation of the score. Oh, well that's so much better than using a program that could convert the same score to MIDI, which the person you want to exchange info with could then use to either obtain the original score, or play it back, or both simultaneously.
There is no advantage here, IMHO these folks learned standards development in Redmond... If you wanted a useful thing, how about a plugin for webservers that could render a MIDI file to readable score? That makes a bunch more sense.
Was there a need for this format? I suggest not. The existing formats, allthough binary handle the job quite nicely. MIDI for example is stable and mature. Not only that it is supported by the companies which make equipment for songwriters and musicians. What MusicXML implies is that there is something wrong with the standard, which is patently false. It is at best poor programming practice to re-invent the wheel, which is what MusicXML aims to do.
Truly the need is a way to render standard music format on the web. Okay, turning MIDI into standard music format is trivial, and allready being accomplished in many devices, and by many programs. What was needed was a way to display the output of this decoding algorithm to a web page, not to invent an unneeded standard.
Really the only purpose I can see for this standard is to sell software which supports it. The fact that no other industry standard equipment is likely to support it shouldn't deter you, look at M$. If enough people do something the wrong way, it still can become a standard.
"Talk minus action equals nothing" - Joey Shithead, D.O.A.
"Talk minus action equals
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
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 necessary, to a variety of formats, including PDF.
In the United States, NMPA/Harry Fox Agency has jurisdiction over licenses to reproduce musical works in formats that a mechanical device can play back. Mechanical devices include player pianos, music boxes, record players, CD players, computers, and the like.
What barrier are you talking about? Neither Netscape 1 through 4 nor IE was free software. Until Mozilla and Konqueror came out, was HTML "free"?
In a couple decades, once public domain preservation projects such as Mutopia and Gutenberg have run out of popular pre-1923 works to transcribe, what will happen to those projects?
First of all, last time I checked, Cygwin didn't work well on Windows 98, which is still installed on many home PCs. A new version of Windows costs $200 plus the cost of hardware upgrades, and it may not work properly with the apps that are already installed on the machine. How do you expect potential Lilypond users to afford this? Or have developers fixed Cygwin to run properly on Windows 9x?
Can the Cygwin version of Lilypond work from within Windows Explorer instead of from within Bash?
And like many other "net installers," the Cygwin installer seems to require a high-speed Internet connection, not the 15 MB per hour dial-up connection that most residential Internet users still have. How many megabytes of Cygwin does Lilypond depend on?
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 with XML files in most languages and on most systems, and DTD's/XSchema tend to be fairly carefully thought out and documented.
Given a choice I'll take the XML format pretty much any time - but then too I can look back and tell you just how much fun I've had coping with binary formatted files (especially those that are un- or under- documented). (No, really, often it has been fun. OK, so I may have a seriously twisted notion of fun, and the fun has often been mixed with serious frustration and pain.)
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 infringe the compilation's copyright unless somebody (who would usually be credited) has noticeably arranged the work. Copyright Office Circular 14 explains: "Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes." You may have read about mapmakers that add fake streets to maps to prove copying. In the case of public domain musical works, this would prove copying but, given uncopyrightability of trivial derivatives, would probably not prove copyright infringement.
That is, unless somebody can respond to this comment with a link to a decision that holds otherwise.
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!
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???
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?
MIDI is to music what ASCII is to art.
MOD is to music what a jigsaw puzzle is to painting.
Well, well... obviously it means an academic do-re-mi partiture written in cotton paper with gold ink is far superior than those geekish music formats. Oh, dear!
May the Lord allow those proletary noise formats die into oblivion!
new bug open,
1
RFE: supports of MusicXML
http://bugzilla.mozilla.org/show_bug.cgi?id=23238
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.-
You XML bashers just don't get it, do you...
It's all about open and standard representation of rich, hierarchical information - XML is just the first widely used, portable, easy to use, domain-neutral way of representing hierarchical information.
XML is the first data representation to recognize that, from the perspective of DTD (domain) authors and software developers, these kinds of things are of the highest importance:
* we can re-use the same damn Xerces parser to read and write ANY XML document (rather than building new domain-specific parsers, over and over again, for arcane file formats which nobody but the creator will ever understand),
* we can make straightforward extensions to the format which don't necessarily BREAK existing software,
* XML is human-readable enough to readily facilitate human sanity-checking of complex documents,
What's NOT important is that we be able to represent Beethoven's 9th Symphony in 27 bits!
Last time I checked, the computer on my desktop had 1GB of RAM and over 100 GB of disk space...
I can comfortably fit 10^5, very beefy, 1000-note songs on my computer without breaking a sweat, and without doing any compression (XML tends to compress very well, by the way - even without XML-specific compression).
On top of that, XML is slowly replacing HTML as the lingua franca of the internet, and of information representation in general. The portability of information engendered by the efforts of organzations such as OASIS, and by DTD's like RSS, RDF, and SOAP would not be possible without a technology like XML at the core.
Don't misunderstand - the folks who have been using XML to make over the world of information don't "love" XML - they just recognize that any equally useful alternative would be just another flavor of the same juice.
And just because it's XML don't mean it's good - there are lots of crummy DTD's designed by people who don't "get it". But that's not XML's problems - and cooperative standards organizations are supposed to keep the overall quality at least high enough to be useful.
Get a clue. The last of you XML bashers will be dead long before XML hits its peak.
switch to sites operated in life+X countries, which release new material into the public domain every year.
Yeah, but when Europe extends copyrights, as it did in the mid-1990s, it actually restores copyright to works that had been PD. Thus, you may have to throw away work you've already done.
This reminds me of something I discussed with my friend recently. She's played a bit of music in the past, and being the scientific type, was baffled as to why we refer to musical notes in the way we do. Twelve semitones, but we use seven letters to refer to them, with all those odd sharps and flats? And all the ridiculous bandwidth we waste by having two or three ways of describing each one (double sharps and flats, anyone)? All sorts of nonsensical stuff.
Of course, it all originates from the design of the harpsichord (I think. Don't quote me on that), but surely in this modern age of open standards and such, some visionary must have come up with a more elegant* alternative. Does anyone know of one?
*though clearly, not necessarily more functional. This is standards we're talking about here.
Bow, nigger. h
. . . they just recognize that any equally useful alternative would be just another flavor of the same juice.
Bingo! He's wrung the bell. Give the man a prize.
KFG
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 ETF, you'll realize it's awfully close what an XML-style data format would be. The first example is a 15-page score with 16 staves, and it's less than a meg!
So MusicXML would scale better than PDFs exactly how?
But for collaboration across multiple programs, of course you need some common editable format.
Viewing something on the web, which is the point of a browser plugin usually isn't for editing and collaboration. If I want people to be able to see and print my scores with ease, I put up a PDF, and nearly everyone can read it. If I put it up in MusicXML format, then they have to go get some random plugin, if one exists for free.
I'm not saving MusicXML would not be useful for saving as a data format. I'm all for it! I'm saying we already have a good enough technology for viewing and printing documents over the web.
So I put my scores up in PDF; for free with ps2pdf.com. You can print them, they look fine, and it already works. Today.
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
Uh, ideally they already do. My point is not that MusicXML is useless, but this:
I have a score on the web that I want people to see.
Given a choice of posting a score on the web, I can: Post in PDF, which looks perfect and requires a freely-accessible viewer that almost everybody already has.
Or post it in MusicXML, which almost nobody can view. What am I going to choose?
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
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 of accidentals. It has trouble mixing parts on the same stave (e.g. complex piano notation). There's no standard for grace notes, cue notes, arpeggios, ornaments, tremolos; no agreed values for dynamic levels or changes. Lyrics cause major problems - even if you use the .kar extension, how do you put multiple sets of words for different voices? Or different verses? There's always a need for other text, too - tempo and style markings, instructions for voices to split, or strings to play near the bridge, or brass to use mutes, or a hundred others. And of course multi-instrument scores are far worse: how do you group certain staves together? How do you show instruments entering or leaving part-way through (common for vocal music)? How do you tell when to use multi-bar rests, or section letters? And that's before we get onto page-layout issues such as title/author/composer/copyright/&c lines, and where to break lines and pages (which no package gets right on its own, and I always end up having to do myself)...
Is that enough to be going on with? :)
MIDI may (for keyboard pieces) give a reasonable description of what one particular performance may sound like, but manuscript is far more than that, telling how to create other performances under other conditions. It tells you the composer's intent in a way that sound or note data simply can't.
Ceterum censeo subscriptionem esse delendam.
Also some of the expensive audio programs do midi to sheet music. logic pro does it (see the sidebar on the right..) and I'm sure there is more.
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!
--
Yes, it can. Work very well for just about any keyboard player on the planet - although some experts at Bosendurfhoer (or however you spell) disagree but their classical ears are so much better than mine.
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 edit.
And yes, yes, yes, MIDI can make very nice sheet music but it does have it's limitation - that other guy was right. I had forgetten that my favorite music software (Melody Assistant) actually has many extension to the MIDI standard, but the truth is, I don't use them much.
For me, notation is a means to program the synth, not a end to itself. I never actually READ the bloody stuff when I'm playing. You heard the ole joke about how to shut up a guitar player?
You hand him some sheet music.
The above article is both Interesting and Informative. Somebody with mod points please take action!
-DA
Last time I checked, bug reports filed on /. were directed to /dev/null. Cygwin works well, on all *released* versions of Windows; if it does not work
for you, please file a bug report instead of spreading FUD.
We can have it both ways, if we use a XML format for tools and a more concise format (such as moo2midi) for manual editing, and write a good converter between them. Of course, making the conversion work bidirectionally means some difficulty in designing the text format.
...tab's easy: it's ASCII - you can mail it very simply. Musical scores are graphical, but lend themselves to a standardised file format as otherwise you've got the aforementioned JPG scans...
Representing a whole note with a circle is like representing an "O" or "0" with a circle: ugly, ugly, ugly.
If you want decent musical notation, you pretty much have to use a music font.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Whatever. As a data storage format XML is superior.
musicXML's own web site describes it as useful for "common Western musical notation from the 17th century onwards." well, great. so i can't annotate unusual Western classical music, or popular Western music, or classical Japanese music, or even Gregorian chants? perhaps this will truly be useful for some people, but those of us looking for an abstract solution (!) cannot be satisfied.
technically, the schema is heavily dependent on then nuances of specific classical instruments and the 12-tone scale. i think that any *modern* scheme will represent other tunings and timbres.
Thank you for letting me know that the Cygwin infrastructure has improved in the last few years. But a question remains: how many megabytes of Cygwin binaries do I need to install before Lilypond will work as advertised?
Tarditional notation falls short of being useful to a machine in the same way MIDI is, i.e. a sequencer doesn't give a rat's ass what your score looks like, it only wants a DIGITAL FILE format.
Both formats are lacking music concepts outside of "traditional," and while you may not care, there is a good portion of music in the world that cannot be caputured by current notations on account of them not being EXTENSIBLE in the same way an XML one is.
The new format is machine-usable the way MIDI is and still translate to both traditional score and MIDI very easily (as long as the translated type can cover it).
Is it really so bad having a language that is machine-readable/playable and still captures the the "human side" of music?
Ha! XML is not a data storage format. At least it is not supposed to be a data storage format. Ask the people who 'invented' it.
o -world.gi f
m l
We have far, FAR better data storage formats (binary, etc.) for just about any purpose.
MusicXML is a horrible, horrible idea. We have a perfect way of showing a human-readable format:
http://www.recordare.com/xml/images/hell
Look at this:
http://www.recordare.com/xml/helloworld.ht
ONE NOTE!!!WEFSAFD
Is this not insane? Why does no one see this as ridiculous?
Thanks,
--
Matt
You are very right that MusicXML is not the best for human readability. It was designed for computer readability. I'm sure you would be even less pleased by a binary format.
You are an artist, a composer. You do not really have to look at the guts of the data format for Music XML or PDF or whatever. Computer jockeys do, however, have to look at that stuff. Trust me. It is better to have an open standard like XML than a proprietary standard like a binary format. As for PDF, it works for display but is awfully unwieldy as a storage format.
Take an example. Let's say you've written your masterpiece. Unfortunately, the art world is too cynical and they don't recognize you. Gradually, all of your musical works crumble into dust, totally unnoticed. Fifty years after your death, some young fellow comes across the last surviving remnant of your work. This also includes your masterpiece. Unfortunately, this person has no idea what he is looking at. All he sees is a file marked
JDU377WTX.FTF
He opens the file up, notices it is a binary file, and deletes it.
Then he moves onto the next file. It is marked:
JDU377WTX.XML
He opens the file up, notices it is XML, plugs it into his super-duper-future-web-browser, and--pow, up pops your masterwork, perfectly represented as sheet music. Since this person is a musician and has an open mind, he recognizes your greatness. Soon your masterpiece is beloved by billions of people all over the world. Statues of you are placed in the great concert halls of the world. Women name their babies after you. Young artists are inspired as never before.
Good thing you saved it in XML and not just a non-standard proprietary data format.
The real deal is SMDL - Standard Music Description Language, an SGML based language under dev now since forever. This is a closed and proprietary XML system from a group that has spammed me for years.
More info - http://xml.coverpages.org/smdlover.html
Calling the Ricordare system Music XML is like calling ALICE AIML.
http://alice.sunlitsurf.com/alice/aiml.html
idealord music
"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
"Music written on the staff", sometimes referred to as Common Music Notation (CMN*), is spacially sensitive in two dimensions and uses a set of symbols for which there is no single unambiguous ASCII representation. As such CMN itself cannot be considered a computer language or file format. To say that there's no need for a new notation file format because CMN already fills that niche is thus mistaken.
It would be valid to recommend using graphical image files containing pictures of CMN as a music notation file format. While this is perfectly useful for purposes of saving and transmitting notation data, it does make loading notation data into an editable data model an extremely difficult task, because Music Character Recognition (MCR, similar to OCR) would be required each and every time. MCR is not only computationally expensive, but is also a very young, imperfect technology, which is far from reliable.
Part of the reason why MCR is so difficult is that despite its long history, or maybe because of it, CMN is *not* a "robust, well designed language". It is an ambiguous, self-contradictory language which requires a huge amount of knowledge beyond what is printed on the page in order to correctly interpret the data. In a way, it is a lossy compression format similar to wavelet compression of graphics; a large database of extra information is needed for decompression.
As far as MIDI is concerned, there is indeed enough information in a Standard MIDI File (SMF) to notate many types of music. However, there is not enough information to convert reliably into CMN (as other posters have already described). Instead, MIDI is commonly notated in the form of a piano roll, or as a textual event list. While these are real and valid forms of music notation, most musicians cannot or will not read them. If your audience insists on CMN, then you need to give them CMN.
In any event, it might help to restate the problem more explicitly: MusicXML attempts to provide an easily loaded, lossless computer file format for an abstract representation (data model) of a piece of music optimized for editing and sufficient for converting into CMN. How well it meets these goals has yet to be seen.
* Note that the term "CMN" here should not be confused with the Lisp-based music notation language of the same name; I'm speaking solely of the typeset output.
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.
Thank you for the positive moderation BUT... ...i was a dufus. I realize now that is *only* about music NOTATION. Sheet Music. Staves and black marks and such. And that actually is COMPLETELY out of the scope of the MIDI specification and probably will be for forever. The notation of music in 2D dimensions on a static page has zero to do with a Musicial Instrument Digital Interface. Sorry about the confusion.
Folks outside the field may not realize that MusicXML already works with the two market leaders in music notation software. Finale can both read and write MusicXML files, while Sibelius can write a more limited type of MusicXML. The Finale support is currently Windows only, but we are busy working on the OS X port. MusicXML is already second only to MIDI in its adoption by music notation applications. It's nowhere near as universal as MIDI (yet), but it's a lot more complete for music notation!
One point that seems to have been missed in the discussion is that standards can reduce the barrier to entry for innovative applications. With MusicXML, you can use programs like Finale as your "notation engine" handling the standard parts of music editing and display, while your own application more innovative work. So electronic music stands like MuseBook Score use MusicXML for input, while algorithmic composition programs like JMSL use MusicXML for output. More details about MusicXML support are here.
A theme finder like your describing already exists. Try themefinder. It provides just that capability. The problem - it only knows how to read music files that have been transcribed into the humdrum format. If everyone used the same format for describing music (ie. MusicXML) this web site would be a lot more useful...
The number you have dialed is imaginary, please rotate your phone 90 degrees and try again.