I need to give a huge shout-out to Dr. Steven MacCall at the University of Alabama under whom I did the research for MXMLiszt which included delivering the software and a paper – that's much longer than the published one! – about libraries and digital sheet music. It was cool to finish up my library degree with stuff that meant more to me than just a means to, well, finishing up the degree.
…
Update, November 26, 2011: I should have mentioned that this article is not openly available. If you want to read the article but can't access it through your institution or local library, please email me at "nitaro74 AT gmail DOT com". Under the publication rules, I am allowed to distribute the version of the article I submitted to the publisher. I don't have any problem doing so if someone is genuinely interested provided you agree not to openly distribute copies and provided you check with your local library first. Most libraries have access to more resources than most of their patrons know!
MakeMusic, the company behind Finale, has entered into an agreement to purchase Recordare. You can see the press release here but here's the really important part (hyperlinks mine):
Under the terms of the agreement, MakeMusic is purchasing the MusicXML™ open format and Dolet® software technology, including copyrights, source code, and trademarks. MakeMusic also announced that the founder of Recordare and inventor of MusicXML, Michael Good, will be joining MakeMusic as the Director of Digital Sheet Music.
A few people, myself included, were both excited for Recordare/Good but were also wondering what this means for the future of MusicXML in terms of remaining open so here's the scoop – posted on November 2, 2011 – from Michael Good himself on the MusicXML discussion list:
… MusicXML will remain an open format. MusicXML will continue to be licensed under the same open, royalty-free terms it has today. MusicXML's value comes from being an open format that anybody can freely use in their products and services. That will not change. Community development of future versions of the MusicXML format will not change. What will change is that MusicXML will now be supported with a larger company with more resources. There are exciting possibilities ahead!
Personally, I'm not worried.
In terms of XML approaches to music encoding, there's MusicXML and then there's everything else. Mr. Good's known all along that building relationships that ensure software support is a key to success for the format. He's even been kind to the little guys: emailing me and commenting on this blog in regard to some of my work with MusicXML for digital libraries.
So congratulations to Michael Good and MusicXML. I'm looking forward to hearing the next movement.
I've generally heard this quote attributed to Pablo Picasso but also to Igor Stravinsky. It's interesting to think that since they knew each other, one might have stolen it from the other. Related, I glossed over this post on About.com. I didn't read it carefully, but I agree that the quote is misunderstood. I've had discussions in the past with friends who simply invoked the quote to justify lifting parts of someone else's work in the pursuit of trying to create. But as I'd say to them, that isn't stealing, it's only borrowing. If you steal something, you make it yours, making it work so well in your image that it's no longer immediately recognizable as having belonged to another.
Anyway, this post is about digital music notation. Or so says the title.
I've long wondered – even going back to music school in the 1990's – about using a stylus to enter music onto a drawing tablet or what not. And I'm thinking about it more and more. I saw this thread about the possibility of MuseScore on Android tablets, etc. and using the touchscreen interface on a tablet computer as a desktop/mouse replacement, but I keep thinking about the stylus.
Why? Because I hate entering music in score editors. I find it infinitely faster to write music with pencil and paper. I think a large part of this is that there's no translation occurring in my mind between hearing/visualizing what I need to enter and then mapping that into how that gets entered in a score editor. Arguably, some of that irritation would get reduced with practice, but not really in my case because I just don't think that graphical entry via keyboard or a note palette is the way to go.
When I write with pencil, I usually jot down the notes for a small phrase, etc. and then add the stems in afterward. I think that way the part of my brain thinking about notating pitch and duration are slightly separated which for me, at least, makes the process faster. Sometimes I enter each pitch and its duration note-by-note, but it's not conscious and it's still fast. With digital, I find it a royal pain in the ass trying to enter pitches first and then changing their durations. Often, it seems to "break" the measure and cause encoding problems. Going the other route (entering the durations first) doesn't work either. They're both so much more work than the traditional pencil and paper routine. And I end of spending more time thinking about notation entry than Music.
That's what I love about Lilypond. I love how I can just enter into a simple text string just the note names and then go back and add the durations – there's no digital/graphical veil. In terms of computing, it seems a more native and natural approach to use simple text entry than to try and emulate ideas from the pencil and paper world (but do it less efficiently). In fact, Lilypond is the only thing I could use to notate a score as I compose it. That's what I did with this piece for solo guitar. It would be great if MuseScore had something similar to a text-only entry box that rendered as graphical notation after-the-fact, kinda like what happens on weblily.net. I almost want to say Finale does (using some custom text notation syntax) but I can't seem to find a screenshot or anything in the online Finale manual.
I just feel like maybe we're borrowing when we should be thinking about stealing. If we're going to pursue graphical ways of digital notation entry, I think we've got to think about being able to offer users the ability to draw their music with a stylus (more precise than a finger) and having that instantly recognized via OMR. That experience won't be too great on a tablet, but maybe one day with better digital paper and smart pens:
What happens when you have to erase something?
Maybe I'm just an old fogey, but for now I'll stick with pencil and paper and just using a computer to make the music more legible after the fact. There's one enormous advantage to this, too, and it's a musical one: it forces conscious consideration of revision upon me as I "re-notate" the music. Honestly, I doubt I would ever want to not use pencil and paper anyway. Music is the one thing I can do without needing a computer at all.
If anyone's interested, MXMLiszt version 0.9.2 is now available for download.
MXMLiszt is a web-based delivery and search/retrieval environment for MusicXML files and their manifestations.
The documentation and source-code download links are available here.
Here's the changelog:
0.9.2
- included Bach and Schubert MusicXML files from MusicSQL project (http://musicsql.googlecode.com/).
- For the Bach, cleaned up diacritics (in titles only) and changed "Soprano", etc. to "Soprano", etc.
- diacritics are still messed up in lyrics. I'm too lazy to fix them. :]
- For the Schubert, changed "Part_1" through "Part_4" to "Violin 1", "Violin 2", "Viola", and "Cello".
- original files available here:
http://musicsql.googlecode.com/files/Bach_SATB-1.0.zip
http://musicsql.googlecode.com/files/Schubert_quartets-1.0.zip
- adjusted <hr> rules in style.css to accomodate Internet Explorer 9
- Removed "optimized for Firefox" in welcome.php since MXMLiszt now works well in IE, Firefox, Chrome, Safari, and Opera (see below).
- fixed generateIndex.php so the <img> tag now closes in this line:
echo nl2br('<img src="png/' . $filenamePlain . '.pre.png" />'); //line #12
- This was the only reason the Index view wasn't working in Opera.
- Opera was the only browser that caught this error. :]
- made "Results" header for search results an <h2>, just as with the MIR results header.
- added two modules: startWatch.php and stopWatch.php to reduce coding redundancy in regard to reporting the time it takes for actions to finish.
- changed mxml2mods.xsl to output the MODS namespace.
- adjusted mods.xsl, loadMODSasDC.php, and XQuery syntax as needed.
- Sample XQueries using a namespace prefix:
This is a Faust query example:
declare namespace mods = "http://www.loc.gov/mods/v3";
for $x in doc("../concat/concatMODS.xml")/hyperMODS/hypoMODS/mods:mods
let $x1 := $x//mods:subTitle
return $x1
This is a Dante example:
declare namespace mods = "http://www.loc.gov/mods/v3";
for $x in doc("../concat/concatMODS.xml")/hyperMODS/hypoMODS
let $x1 := $x/mods:mods
where $x1//mods:subTitle contains text "You"
return data($x/@file)
- simplified some of the built in MODS related XQueries (same functionality, just less wordy).
- changed order of MODS search drop down terms on Search page.
- changed <i> and <b> to <em> and <strong>, respectively.
- replaced "pop1", etc. with better-named CSS variables like stickyNote and IndexPopup, etc. in style.css.
- added a streamed comment in each module with a one or two sentence description of what it does.
- added .htaccess file.
- to hide root folder.
- to make the "/~foo.xml" forward (with masking) to:"transmuteMXML.php$fname=musicXML/foo.xml".
- adjusted mxml2mods.xsl accordingly.
- to hide directory icons.
- to use fancy indexing.
- changed displayMODS.php to display MODS files via an <iframe> only as a fallback if PHP XSL processing not available on server.
_______________________________________________________________________
0.9.1
- created mods.css file to display MODS on a transparent background.
- changed displayMODS.php to display MODS files via an <iframe>.
- The previous version was using the mods.xsl stylesheet to parse the MODS element values in real-time.
_______________________________________________________________________
0.9.0
- this was the first version - that worked!
When MuseScore first came out, I think a lot of people knew it was going to be great.
And it is. It's also getting better all the time.
One thing that wasn't great initially was the Lilypond export. But MuseScore version 1.0's Lilypond export seems really good from initial experiments I've done.
And let's face it – that's the holy grail of music notation: a GUI score editor with good Lilypond export … AND MusicXML support … and command line options.
So in other words, a one-stop shop for music notation that supports the best tool (Lilypond) for output in terms of aesthetics and the more widely supported XML format in MusicXML … as well as those command line options for using on a server.
Thomas Heck's "Expanding the GFA's Online Resources" from a recent issue (Vol. 36, no. 3) of the Guitar Foundation of America's Soundboard listed some cool online resources that I know of and use and some that were new to me.
The coolest of all is the Boije Collection which I backed up to my local drive and all my backup areas as soon as I learned about it a few years ago.
I will never in my life learn a score by reading it off a screen, but I can print scores out from this collection and work on them. Given that it's mostly a 19th century music collection, it fits perfectly with the type of repertoire I work on. Thankfully, the scores are hand-written, if not facsimiles, as I really hate working on scores produced by machines. They aren't beautiful and don't look alive even though the music itself is. Also, they make learning the music harder for me and less fun. I could go on …
I've made some minor changes to MXMLiszt to address a bug that began to appear after months of trouble-free performance.
So here are the changes I made to address the issue related to the display of MODS metadata:
Created mods.css file to display MODS on a transparent background.
Changed displayMODS.php to display MODS files via an <iframe>. The previous version was using the mods.xsl stylesheet to parse the MODS element values in real-time.
You can read the documentation and download the source code for version 0.9.1 here.
OMET, an acronym for Online Music Editing Tools, is a project to develop a group of web-based applications for creating professional-quality music manuscripts.
Basically, this is a browser-based GUI Lilypond editor. Very, very cool.
Right now it's limited to guitar scores – though nobody should take that to mean notating guitar music is a simple task, given all the resources of the instrument. Add to that the nature of polyphonic music notation on a single staff and, well, "issues" arise.
I signed up for this project's mailing list to keep up-to-date with its progress.
I just saw the posting below in my email today. I'm certainly going to see if I can submit something on MXMLiszt …
Call for articles: Music information retrieval (MIR) special issue
_OCLC Systems & Services: International Digital Library Perspectives_ (OSS:IDLP) will be publishing a special issue on music information retrieval (MIR) and libraries. The editor is looking for articles that articulate the planning, development, testing, systems work, marketing, etc. related to MIR, as well as the challenges of providing access to MIR materials. Articles can be of any length, and figures and screen shots are encouraged. OSS:IDLP is a peer-reviewed journal.
If you are interested in contributing, please send the editor your name, a short proposal of the topic, and a tentative title for the article. Deadline for proposals is September 1, 2010. Articles would be due to the editor by February 1, 2011. Any questions and proposal should be directed to the editor, not to this listserv. Thank you.
Dr. Brad Eden
Editor, _OCLC Systems & Services: International Digital Library Perspectives_
Associate University Librarian for Technical Services and Scholarly Communication
University of California, Santa Barbara eden@library.ucsb.edu
