Beautifully Rendered Music Notation With HTML5 259
An anonymous reader writes "This is incredible. This guy has built a music notation engraver entirely in JavaScript, allowing for real-time music editing right in the browser. Here's a demo. The library has no external dependencies, and all the glyphs, scores, beams, ties, etc. are positioned and rendered entirely in JavaScript."
All this goes to show is (Score:1, Informative)
that no Web browser has a decent typographical engine.
(I know it is not a trivial task to create one, even for just Latin-based languages, or even just English.)
It has external dependancies (Score:3, Informative)
Block google and see how well it works.
Comment removed (Score:3, Informative)
Good job. Need more. (Score:5, Informative)
Only relevant (Score:5, Informative)
http://0xfe.muthanna.com/jsnotation/vexnotation.js [muthanna.com]
this is the code responsible for generating the content.
Re:Not Sure if You Can Call That a Demo (Score:4, Informative)
Huh? The linked demo is a full demo rendered using the canvas element. There's no parser but the generation code is launched via jQuery is clearly visible at the bottom of http://0xfe.muthanna.com/jsnotation/vexnotation.js [muthanna.com] :
Re:It has external dependancies (Score:4, Informative)
http://jsbeautifier.org/ [jsbeautifier.org]
Try not to get too hung up on deciding if the name is impossible, it works great.
Re:It has external dependancies (Score:5, Informative)
Re:Does'nt work in Firefix 3.6.3 (Score:5, Informative)
It's a demo of the rendering engine. Those are not screen shots. What you're seeing is canvas elements drawn on by JS.
It doesn't look as if he's done interactivity yet.
Re:Not Sure if You Can Call That a Demo (Score:5, Informative)
Firefox apparently lets you view or save the current state of a canvas element in PNG format. If you inspect the web address of the PNG, you'll see it's a data: URI.
data:image/png;base64,iVBORw0KGgoAAAA
This capability doesn't seem to be present in Apple Safari; Chromium has an open feature request for it.
http://code.google.com/p/chromium/issues/detail?id=19277 [google.com]
Not beautiful, doesn't look engraved (Score:1, Informative)
Th notes for that music could fit onto a rectangular grid. It looks computer generated, and has not taken into account things that make note placement more "beautiful". Notes should generally line up on the vertical, but the width of space taken up by each whole note shouldn't be constant. I see lots of wasted space and visual gaps in what has been rendered in this demonstration.
See here for more details:
http://lilypond.org/about/automated-engraving/software
Re:It has external dependancies (Score:3, Informative)
He's using google so that people's browsers have a chance of retrieving their cached version, loaded from another site. This is the Right Thing to do.
Re:HTML5 Canvas not supported on this browser. (IE (Score:3, Informative)
Re:It has external dependancies (Score:5, Informative)
Comment removed (Score:3, Informative)
Re:Good job. Need more. (Score:3, Informative)
I read you post as: "I know some basic things about music and need others to know that I do."
I think you mean, "basic things about performing music..", and he actually has a good point. The accidentals are too small in proportion. Zooming out the test samples to about 75% makes them about equal in size to my printed scores, but then the accidentals have practically disappeared...
By contrast, the accidentals in the printed score are much larger. The central portion of each - the bottom of flats, center square of sharps is the same size as the note heads, and the extending lines make them 2-3 times taller.
Overall it looks good, but there's a few issues like this in there to iron out. Making scores easy to read is no easier than typesetting any other stuff.
Re:It has external dependancies (Score:3, Informative)
Do you not see the "min" in the script file name? which means its been "minified", which means the whitespace has been removed, which pretty normal for JS files these days. makes the file much much smaller to ease transport across the wire, and a subtle way of confusing casual JS newbs (like your self) as a very futile attempt at security.
Re:Music typesetting isn't as easy as it looks (Score:3, Informative)
There are also lots of examples where layout improves the usability of score. Some of them are really quite subtle with the results looking 'right' or 'wrong' to an experienced musician and are tied up with how musicians actually used scores - for instance pattern matching on chords and phrase shapes rather than interpreting each note dot.
As for implementation technologies, it's more a case of tools and libraries available. If converting from MusicXML, there's an awful lot of heavy lifting involving XML, and having decent collection classes makes the data structures and algorithms much easier to implement. I'm currently implementing in C#.Net, but would have been equally happy with C++/STL/Boost and a XML to object mapping layer of some kind.
Re:Music typesetting isn't as easy as it looks (Score:4, Informative)
- What proportion of users really care about the finesse of the layout? Most people are happy with MS Word's typesetting, and don't really notice the improvement in a TeX typeset document, for example.
I'll admit that it does take a trained eye to actually spot the differences in a TeX output versus something crappy from Word. But much of the improvement with TeX, though subtle, can actually facilitate reading. I don't know if those effects are really large enough to measure well, though. I notice them because I know they are there.
Music notation is a different animal. You can usually read text at your leisure, and if you misread something the first time, you can go back and read it again. With music notation, you should be able to read it accurately in real time, and that means any little thing that you stumble over can be an annoyance to a performer. Suddenly, you feel the need to mark up the score to point out that sharp you missed, the extra beat that was obscured by poor spacing, etc.
Obviously, standard notation applications have been producing crap layout for decades, so I suppose people have gotten used to it. But I have done a lot of work with Finale and Sibelius (for example), and I've used music typesetters that are better at spacing (e.g., Lilypond). The Lilypond output actually is easier for me to play from, even in pieces I've written or know really well. Yes, this is anecdotal evidence, but I have a lot of friends who are professional musicians that have agreed (even if they use Finale or Sibelius themselves because they are easily available and WYSIWYG). Finale and Sibelius have gotten a lot better over the past decade, but a lot of that improvement has to do with better automatic spacing algorithms.
Re:It has external dependancies (Score:3, Informative)
The official site recommends you load it from google [jquery.com]. Why? Cause the fine folks at jQuery make a kick-ass javascript library, not a global content distribution network.
If you hotlinked the library from the official site, you'd basically be a leech and worse, your visitors would probably not get any of the benifits that come from loading jQuery from google (namely the fact the visitor probably has the google version in their cache already).
Re:A third music mark-up language? (Score:3, Informative)
Re:It has external dependancies (Score:3, Informative)
Actually, even the minified version is 72k, not 24k,
It's 24k after gzipping. You do serve text content gzipped, don't you?
It's possible that there's a different version in play here, but the 24k figure is what I'm getting from the latest version. [jquery.com]
And of course the only way to verify that the minified version doesn't pull in more stuff
jQuery? It doesn't.
since the source script is, for all practical purposes, semi-obfuscated.
That's like bitching that you can't figure out what Firefox is doing, because you only have a binary. It's jQuery! The original, un-obfuscated source is available, along with full version-control history! Unless they've gone out of their way to be difficult, you should be able to verify (with diff) that the version they are using is actually a particular version available for download from jquery.com.
If the "only" purpose was to run the script, a simple body.onload() would have done the job,
Except that's not what jQuery does. If your browser supports it, it's actually onDOMReady [jquery.com]. There's a world of difference between those -- onload requires everything to be loaded, including images, movies, everything. onDOMReady only requires the HTML DOM itself to be finished loading, which is going to be considerably faster -- but it's still enough that your script knows what it's dealing with.
If your browser doesn't support that event, I believe jQuery will emulate it via polling. I'm not sure if it ever falls back to load.
But no, body.onload() is not equivalent. You could certainly do onDOMReady yourself, if you were really determined not to have external dependencies, but that could be said of anything included with a library.
as would calling the first function from an embedded script tag at the bottom of a demo page..
I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag, which makes sense. Progressive enhancement is good design.
Re:Music typesetting isn't as easy as it looks (Score:2, Informative)
Converting from MIDI into score is difficult - particularly so if the music is not synchronised with the beat clock used by MIDI. Variation of the length of notes relative to their notated duration and uneven distribution of beats (or their subdivisions) is an inherent feature of human performance, but makes process of determining the note length difficult when converting MIDI to score. In practice, some degree of quantisation is required to prevent conversion into ludicrously complex rhythms.
Besides notes, there are enormous numbers of score features that MIDI cannot represent - such as slurs, multiple voices, articulation marks, dynamics markings and so on.
There is a Yamaha MIDI profile called XF MIDI that can carry the additional data required to reconstruct a score. It's used by the score display functionality in various Yamaha keyboard models. Realistically, the only way to use it export the output of an engraving or optical note recognition package into it. As far as I know it is not supported by any of the major engraving platforms.
Since MusicXML can optionally carry presentation data for playback, this is a much more realistic prospect as there is plenty of application support in the DAWs, and also in Cubase which has score editing capabilities as well.
Re:Not beautiful, doesn't look engraved (Score:3, Informative)
Hey, it's standard practice to respond to alpha "proof of concept" examples by ignoring the achievement and picking apart the cosmetic details.
An experienced developer will take this as meaning "We're really impressed by what you've shown us, but we can't admit that (for some unstated reason), and we can't find anything consequential to criticise, so we'll attack you for not having delivered a polished, finished product." I.e., it's really high praise camouflaged as criticism.
I've seen it over and over.