I went through almost all of the links that were posted, and glanced over the various options for languages, rendering, and formatting.
Question 1. Canvas or SVG?
This is actually a no-brainer. The library was designed such that alternate rendering backends could be easily plugged in. I went over some of the SVG specification documents, and it appears (at first glance) that I could add SVG support pretty trivially.
So, the answer to this is: Yes, there will be SVG support.
Now, that said, I had two primary goals for this project. One was the ability to render pleasing-to-the-eye musical scores, and the other was to be able to support interactive scores (to allow for building tools such as score editors.)
These goals are potentially conflicting, because certain aspects of rendering perfect scores are actually computationally expensive, requiring multiple passes on the notation. This could affect the snappy-factor of interactive scores. There's also the question of whether SVG is flexible enough for animations and interactive graphics.
Anyhow, I'll dig into this some more and report my findings. Worst case, SVG will be used for rendering static scores, and Canvas for interactivity.
Question 2. MusicXML or ABC Notation or JSON or Lilypond?
I eschew XML. It's clunky. It's difficult to parse. It's difficult to read. It makes my head hurt. So I'll let someone else build a MusicXML importer for the API. (Yes, I do realize that SVG is XML too, but generating XML is far simpler than parsing it.)
ABC Notation. Love it. It's going in. I'll have to figure out a way to lump in easy tablature support.
JSON. This is a good idea in theory, but getting the schema right is the tricky part. I'm going to hold off on this for now and defer to the API.
Lilypond. Although the generated scores are beautiful, I'm not particularly a fan of the TeX-based language. Like I mentioned before, I'd like to be accessible to non-geeks.
Nevertheless, I'm working on cleaning up the API such that it is friendly to compiler-writers, and interested parties can write their own front-ends. A fringe benefit of a compiler-friendly API is the ability to run layout and positioning algorithms on top of generated scores to fine tune the presentation. Kind of like a -O3 for music notation.
Note that these opinions aren't very strong (except for maybe the MusicXML one), and I'm open to other thoughts and suggestions you may have. So... suggest away.
Great! I just saw this referenced from the Ajaxian blog and it caught my interest because one of the first things I did when I got on the internet in the early 90's was managing a country guitar tablature site. I became a fan of ABC later too. And now in my job I've been gaining expertise in javascript.
ReplyDeleteIf/when you setup a source repo, count me as someone who'd like to contribute.
Wow, we both have similar ideas of creating music notation on Canvas, but what you have so far look really promising!
ReplyDeleteWhat I experimented is using Lilypond fonts and a JSON data structure, but whichever format chosen should be able to be converted from one form to another.
http://jabtunes.com/notation/
Thanks for the update on this, I was going to post it on the previous entry, but it's still relevant.
ReplyDeleteThe last thing the world needs is another "music description language" which means you're stuck with MusicXML, the proprietary formats or something based off lilypond.
I know you said you're not a fan of the lilypond based stuff, but the problem is really that describing music is very labor intensive. There is a huge amount of free-ish music described in lilypond, a whole bunch in the proprietary formats (Finale, Sibelius, PowerTab, etc). Anything that lets you leverage those existing description capabilities ~more~ is a good thing.
I understand you like the idea of inventing your own music description format and that makes a whole class of things easier for you but there are huge "traction" issues on convincing people to describe music in whatever format you invent.
Maybe the goals are in some way orthogonal, but don't dismiss lilypond out of hand... simple lilypond is definitely accessible to music geeks.
Take a look here before you diss lilypond-ish stuff too much:
http://www.mutopiaproject.org/browse.html
Unfortunately the simplest I could find was this one:
http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1359
http://www.mutopiaproject.org/ftp/GiulianiM/O50/giuliani-op50n31/giuliani-op50n31.ly
...the "accessible" part I'm referring to is the following:
"""
%5
[a a' c]4. [d a']8 [d a'] [dis a']
e8 gis, b e,4 r8
a4 r8 a4 r8
a4 r8 a4 r8
[e' g]4 c8 [b g']4 [g g']8
%10
c4. d
e4. e,
a4 r8 a4 r8
a4 r8 gis4 r8
a4 r8 d4 r8
"""
...very easy to understand, read, write, etc. Unfortunately there's a lot "around" there in a lot of the *.ly files that makes them complicated.
Maybe you could make at least that basic, internal format be lilypond compatible so that enterprising people would be able to shift big blobs of notes into or out of whatever format you eventually decide on.
--Robert
If you don't go with an existing format, I highly recommend trying out an s-expression syntax. Sexprs are extraordinarily easy to parse and read, they're super compact (certainly compared to XML, but about the same as JSON), and there are already tools to read and write them.
ReplyDeleteIf you want to be accessible to non-geeks, I think you need to go with MusicXML. It's the score format that reaches a far larger population of non-geek musicians than any other. You don't type it in; you use a program like Finale, Sibelius, NoteFlight, or MuseScore to generate it.
ReplyDeleteI guess I don't understand how XML is difficult to parse with its standard syntax and so much built-in parser support - especially compared to abc! abc is easy to type for simple music, but it's hard to parse and semantically it is very incomplete.
If you can support MusicXML you are set up to handle most anything in common Western music created by most any music notation program. If you stick with abc you may be tempted to design for abc's limitations, making it harder to be extensible to more complex music (tab, polyphony, etc.)
It would be great to use your library to create something like Noteflight without the need of plugins or external platforms. We are currently developing an iPad music notation app, but it is a standalone application using Cocoa.
ReplyDeleteIf you clean up the API and allow for contributors, I'd be more than happy to help out.
ReplyDelete-Xal
Before anybody uses musicxml for anything, they should read this recent Linux Audio Conference paper:
ReplyDeleteA MusicXML Test Suite and a Discussion of Issues in MusicXML 2.0
http://lac.linuxaudio.org/2010/papers/19.pdf
Sorry, I should have linked to the presentation slides as well:
ReplyDeleteA MusicXML Test Suite and a Discussion of Issues in MusicXML 2.0
http://lac.linuxaudio.org/2010/download/Kainhofer_Talk_MusicXML_LAC2010_2010-05-04_Presentation.pdf
Most browsers can parse XML for you, then you just navigate the tree using DOM.
ReplyDeleteWell SVG and HTML5 IS XML....
ReplyDeleteTransforming MusicXML into an SVG sounds like a feasible option through the use of a stylesheet or something of the sort.
But nevertheless this seems like a brilliant idea.
But if we can render MusicXML into SVG, and then back to MusicXML then perhaps we can start working on overcoming the MIDI limitations by working on a MusicXML sound renderer? any ideas? any previously done work?
Just a note on my previous comment:
ReplyDeleteI do not in any way subscribe to MusicXML. I just like the idea of developing a standard for music representation. Too bad MusicXML is not as "open" as it should be.
This is a really cool project. It'd be good to have support for chord names written above the music, preferably in some standard format that a script using the API could automatically transpose.
ReplyDeleteLooks like a nice start, congratulations.
ReplyDeleteDon't let anyone try to push you into supporting any file format; the file format is besides the point.
Here are some things to think of:
- you'll need to implement exact rational numbers, your tick based approach will fall apart when you start doing triplets
- have you thought about line-breaking beyond "this does not fit on the line"?
- what about editing? It looks as if you construct the whole thing object-by-object. Does that scale to page sized documents? It could be faster if you do something incrementally, but I could never think of a way to do that cleanly.
good luck!
Han-Wen
(LilyPond main author)
To me, the problem with MusicXML is that it's difficult for a person to write. It's just so verbose and unnatural. ABC lets me write simple bars pretty quickly and about as intuitively as can be expected when it comes to translating text to musical notation. Realistically, it is probably harder to parse, but I think it's worth it.
ReplyDeleteWould you be willing to host your project on github or something so that people who want to contribute can do so easily? :)
ReplyDeleteIf you decide for ABC, you could be interested in the abctab2ps extension by Christoph Dalitz: http://www.lautengesellschaft.de/cdmm/userguide/userguide.html
ReplyDeleteI'm not entirely convinced is the way to go to extend ABC to tablatures but it might give you some ideas.
Han-Wen is of course correct that your internal data structure is much more important than an input format. And if you make everything accessible via APIs, you can let anybody else write an input translator for their favorite format. But I don't see the need for another text-based notation format when MusicXML, LilyPond, GUIDO, and abc are all available.
ReplyDeleteJoao, how is MusicXML not as open as it should be? I like Christopher Blizzard's definition of "open" at:
http://www.0xdeadbeef.com/weblog/2010/04/open-vs-standard/
"It’s open if I don’t have to ask anyone for permission to use it. Or ship it. Or improve on it."
MusicXML meets that test of openness 100%. Its license is based on the W3C's license. It's used throughout the world by open source and closed source projects, commercial and non-commercial, free and pay.
Evan, if this project is trying to reach non-geeks, ease of typing an input format is irrelevant. The vast majority of musicians creating digital sheet music do so with a program like Finale, Sibelius, or MuseScore.
I don't think it's entirely fair to dump on Lilypond because of TeX - and believe me, TeX's oddness turns me off, too.
ReplyDeleteI find Lilypond eminently readable and usable. It's not simple, no, but then notation isn't all that simple, either. The difference between Lilypond and ABC is that Lilypond is more formalized, which is essential once you get beyond very basic scores.
Here's my own guide to Lilypond, just written:
http://createdigitalmusic.com/2010/05/14/lilypond-free-beautiful-music-notation-engraving-for-anyone/
And more thoughts on your (awesome) work:
http://createdigitalmusic.com/2010/05/14/music-notation-with-html5-canvas-in-the-browser-standard-formats-for-scores/
I just wouldn't assume that Lilypond is geek-unfriendly. I think it's probably the only text format out there really usable for notation across a wide variety of circumstances, with the ability to directly edit, and a renderer associated with it on the desktop. (MusicXML is versatile, but as you say, not really usable directly - and there's no renderer, either.)
Sorry, that's non-geek-unfriendly. That's too many negatives.
ReplyDeleteLilypond is not just for geeks. ;)
Ran across the story at slashdot, and it looks really interesting. Something I've long wanted to do at my ABC-related site is add full support for non-Latin1 languages, so I can handle music in Chinese, Arabic, whatever. I've tried doctoring abc2ps to handle UTF-8, but I've never succeeded at making the results display correctly. All browsers now do UTF-8 pretty well, and if this music formatter can be used to get non-Latin1 titles, lyrics, etc. right, I'll switch to it. If you need any contributors to work on parts of it, let me know.
ReplyDeleteAwesome program!
ReplyDeleteI'm currently working on a web server that's designed to host "thing" editors like your music editor. My server will give you a 100% in-browser Javascript API that lets you easily save music back to the server without any server-side coding. My server is also "social out of the box" in that it'll manage users, permissions, and sharing for you. Users will be able to share the music they create with anyone who has an OpenID.
An example that I'm quite proud of is that I very quickly integrated http://canvaspaint.org/ to save images back to my server.
My alpha server is located at http://objectcloud.kicks-ass.net. If you release your editor as open-source, I'll gladly help with integration.
Bigendian, marvelous!
ReplyDeleteI'm a big fan of ABC.
Have you looked at
"CONCERTINA.net - Tune-O-Tron: Converter"
?
Try pasting this (EXCLUDE the "=====" lines)
=====
X: 48
T:Flowers of Edinburgh
R:Reel
O:Scotland
O:Ireland
M:2/4
L:1/16
K:G
"G"GE|D2DE G2GA|BGBd cBAG|"D7"FGFE DEFG|ABAF E2GE|
"G"D2DE G2GA|"G"BABd "C"efge|"D7"dcBA GFGA|"G"B2G2 G2:|
|:"G"Bd|"G"g2gf gbag|"D7"f2fe fagf|"C"edef gfed|"Em"B2e2 e2ge|
"G"dBGB d2dd|"C"edef "Am"g2fe|"D7"dcBA GFGA|"G"B2G2 G2:|
=====
and submitting it.
If you want a SAX (2.0) parser, this one is fairly far along: http://code.google.com/p/jssaxparser/ , but again as someone said, the browser usually does the parsing. If you mean finding specific nodes easily, XPath (especially when using a library to overcome differences in e.g., IE/Mozilla) makes accessing XML nodes very similar to accessing JSON. Great to hear you're going to try SVG, and awesome work man!
ReplyDeleteBigendian, have you checked out ABCJ?
ReplyDelete"The ABCJ Website"
And especially the ABCJ Online page:
.
Try "Flowers of Edinburgh" (above) in it.
And how do you play 2 x x 12 12 12 on the guitar using a single left hand? Unless you are Mr. Elastic or something?
ReplyDeleteThanks for the comments, everyone.
ReplyDeleteA few clarifications:
- I'm not looking for a fully specified music description language. MusicXML is already there and so is Lilipond. My focus is on the rendering engine, and providing a clean API such that others can build importers for it.
- I am, OTOH, looking for an easy-to-type notation for notes and tabs, so that people can quickly type in their ideas and convert them to music notation. ABC notation seems to fit the bill perfectly here (for scores).
@Han-Wen Thanks for chiming in, much appreciated. I did hit the triplet issue recently, and did have a very pronounced doh-moment! I then bumped up the tick-resolution and started using floating-point (and correcting for accuracy, of-course). But you're right, using rationals seems like the cleaner way to do it; I'll look into it.
@Han-Wen Re: editing, I've actually built it such that it can render incrementally (though very rudimentary). One of the things I need to do is compute the successive measures/bars/notes that need to be updated when a note changes somewhere in the middle.
I'm holding off on this until I finish the new layout engine that I'm currently working on. In particular, my previous one didn't account for the correct placement of accidentals and other modifiers (such as guitar string bends).
@peterkirn I don't think I ever "dumped" on Lilypond. I agree that it is flexible and supports many of the really odd cases... but again, that's not what I'm looking for. The API will allow people to import and export to any format, so eventually there may be a Lilypond importer.
And yes, I can fret the second and twelfth frets with one hand. Can't you?
I am of the opinion that people generally use score editors to generate a score, so the readability issue for the input format isn't such of an issue. Since practically everything is convertable from MusicXML, I'd go for that, so Lilypond and all the others can be generated from there. Even Guitar Pro (I'm a fan) is able to import and export MXML :)
ReplyDelete@0xfe: Sorry, I may have used "dump" as I'm usually one of the first to dump on TeX, by contrast. Love the concept; just can't stand the execution. ;)
ReplyDeleteMy point is that it is very possible to read and edit Lilypond's text, which - I agree - isn't true on MusicXML.
But I also agree, ABC may be more appropriate here for the application, because of its simplicity.
The issue, though, is that you may not be able to support rendering Lilypond if you don't support its syntax. I'm not even necessarily saying it's a good idea to do that at all, but I'm not sure an import script will be all that easy -- there would have to be something to map to on the rendering side!
Now, that said, maybe doing something simple based on ABC is a better way to go for this application. I would expect if you got that working, someone could extend that work to do something that would natively render Lilypond.
Also, don't underestimate the ability of Lilypond for easy-to-type notes. If you take out all the fancy formatting notes, it's not all that different than ABC. What you could do is allow people to enter notes or tab in just that block, and do the rest with default templating.
ReplyDeleteI only say this because - far from being a Lilypond expert - I just picked the thing up, and I've been impressed and pleasantly surprised.
So, for instance, I can take this little snippet from a score I just did:
d ef c4 bf
a8 bf c4 d ef8 d c4 d2
So long as you set up the relative note (\relative c) and a voice in which to put this, everything else could be done in templating and global parameters generated on the fly.
We have just released version 1.0 of abcjs, a javascript library for rendering abc in-browser.
ReplyDeleteCheck out http://drawthedots.com/abcjs for real-time abc visual and audio rendering and the project site: http://code.google.com/p/abcjs
Kudos on this work, from someone who tried many times to complete an SVG/Java notation system! This is a great thing.
ReplyDeleteRe MusicXML and lilypond, having used both extensively:
MusicXML is primarily an interchange format, it's horrific on it's own, and no fun to assemble in code. But as an interchange format it is extremely useful for importing into WYSIWYG editors like Finale or Sibelius, for which it's pretty much the only solution.
Re lilypond, I second the above post that it's quite nice as a basic note-entry system, with the added benefit that it goes to 11 if you want to go ahead and create a complex score.
(also the lily open-source fonts are a great source of glyphs!)
Cheers,
Stuart
Nice to see work on this. I have described a similar problem and a similar solution in a list of interesting research projects.
ReplyDeleteYour example doesn't run fully in Opera, you may want to take a look in the error console.
Your proposed language looks a lot like CSS, perhaps you could make it fully compliant?
If/when you open up the code, I'd be prepared to look at writing a MusicXML parser.
ReplyDelete