A Question of Formats
Firstly, a big Thank You to everyone for the comments and advice to my previous post.
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.
34 comments (imported from blogger)
If/when you setup a source repo, count me as someone who'd like to contribute.
What 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/
The 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
I 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.)
-Xal
A MusicXML Test Suite and a Discussion of Issues in MusicXML 2.0
http://lac.linuxaudio.org/2010/papers/19.pdf
A 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
Transforming 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?
I 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.
Don'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)
I'm not entirely convinced is the way to go to extend ABC to tablatures but it might give you some ideas.
Joao, 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 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.)
Lilypond is not just for geeks. ;)
I'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.
I'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.
"The ABCJ Website"
And especially the ABCJ Online page:
.
Try "Flowers of Edinburgh" (above) in it.
A 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?
My 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.
I 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.
Check out http://drawthedots.com/abcjs for real-time abc visual and audio rendering and the project site: http://code.google.com/p/abcjs
Re 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
research projects
.
Your 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?