Beautifully Rendered Music Notation With HTML5
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."
Block google and see how well it works.
I can almost hear the thundering footsteps of developers rushing to HTML 5. I have to admit, I'm one of them.
Surely this is just a tool for the copyright infringement of the RIAA's music?
Stick Men
I'd like to see accidentals rendered larger. Check Wikipedia and you'll see they're as large as the note bodies; check this guy's notation and they've gone all squinty. When you're a musician and you're playing notes that suddenly have to be modified, the last thing you want is to break concentration by trying to figure out which modification to apply. These things need to be properly proportioned. Time signatures would be handy. All that said, this looks like good proof-of-concept. I'd use the hell out of it should it become available.
The pain was excruciating and the scarring is likely permanent, but that just means it's working.
part for the coders is:
http://0xfe.muthanna.com/jsnotation/vexnotation.js
this is the code responsible for generating the content.
And here I was hoping they'd do the obvious and give us beautifully rendered Rickroll tabulars.
Are the png's you are talking about somewhere in here:
http://0xfe.muthanna.com/jsnotation/vexnotation.js
Or are they somewhere else?
Nerd rage is the funniest rage.
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 :
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.
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
org.slashdot.post.SignatureNotFoundException: ewg
He's not talking about IE, he's talking about IE9. According to the numbers from Wikipedia, FireFox has 31% of the market, IE 8 has 22%, IE7 has 14%, IE6 has 21%. No single version of IE has more market share than FireFox and, given that IE9 won't run on XP, I doubt that IE9 will gain market share any quicker than IE8 has done. IE market share overall has been dropping by at least 1% per quarter for a few years. IE9 will face an uphill struggle to gain a significant market share.
I am TheRaven on Soylent News
I get the same in Chrome 5.0.375.29 beta.
I *know* Google Chrome supports HTML5 and <canvas>, so I'd say his page is broken.
Works in Safari properly. Your Chrome beta is exactly that, a "beta".
People are already playing with some parts of it:
http://www.bramstein.com/projects/typeset/
Nerd rage is the funniest rage.
We already have MusicXML and TeX/LilyPond for music mark-up. I'm not sure what benefit there is in a completely new mark-up language. However, an open-source web rendering tool for these languages would be extremely useful.
But can we cool the HTML 5 hype engine, seriously? This is a very minimal demo, just like every other "Look at the amazing power of HTML 5!" site I see. There are Flash-based music sites out there with dynamic scrolling, multi-track MIDI playback and lots of other features, and nobody calls them incredible. I look at the moving dot demo and then go back to Prezi, or listen to all the stuff about video in HTML 5 and then go work in Kaltura for a while
HTML 5 has a lot of potential. But it's hardly some amazing thing that brings new capabilities to the web. All of this is possible now. You may not like how it's done, but all HTML 5 is going to do is change the underlying tech, not give us lightning.
"Seven Deadly Sins? I thought it was a to-do list!"
Achieving a rendering of very simple scores such as these is easy, but coping with anything more complex starts becoming a difficult data structures and algorithms problem really quickly, and the layout rule-set becomes increasingly complex in order to handle the myriad corner cases.
What we see here is a great start, it demonstrates that it's possible to render music symbols in HTML canvas, but it's very far from being a complete music typesetting solution that can take an arbitrary description of a score and produces rendered output, which is the impression conveyed to many of those commenting here.
The data model of the score in the example is generated programmatically (it takes up about 1/3 of the javascript file) and is fairly simplistic. This is an important consideration as the only sane way to create and edit scores is with a graphic editor of some kind, such as Sibelius, Finale, Notion or a bunch of open source alternatives.
Increasingly the de-facto interchange format for these is MusicXML, however MusicXML is largely a semantically oriented description of the score with optional positional data rather than a presentation-oriented one. Indeed, if a presentation oriented description is what you required, you might as well use SVG to start with.
Generally the approach one would take would be to convert the MusicXML data model into a presentation oriented one, applying layout rules as you go.
The small amount of layout logic here is very simplistic. Things become much more difficult when multi-stave scores, paging, line-breaking and justification, slurs and so on. I'd would also suggest that whilst implementing the complex algorithms and data structures required in Javascript is certainly within the bound of possibility, it would not be easy, and wouldn't be my first choice of implementation technology.
Hi, I’m a real typography geek. (Chorus: “Hi, typography geek!”)
*Real* typography geeks say Knuth got everything wrong.
Sure we do. We know Knuth was crazy to talk about paragraph-based hyphenation and justification, and it is madness that the Knuth-Plass algorithm remains the gold standard in H&J today and something that only TeX itself, InDesign, and a few high-end specialist packages can match even now. We hate all those fiddly thin spaces that you have to type manually, too; we’d much rather just have our adjacent quotation marks and superscripts clashing.
Speaking of superscripts, we know Knuth’s font design skills were appalling as well. Anyone could design a system of fonts that was still clearly legible when used to typeset mathematics with sub-subscripts at 4/5pt on the one hand, yet provided extensible brackets surrounding multi-line expressions without looking overly large on the other. We know this from the vast number of font families available from the world’s leading type foundries today that do the job, and the way mathematical journals have given up on TeX because modern fonts provide a much wider range of mathematical symbols that are still clearly distinguishable from any Latin or Greek glyphs that may appear nearby.
Maybe TeX was just behind the times, though. After all, in an era when TeX could only typeset a variety of proportional fonts with intelligent hyphentation, ligatures and correct punctuation, at a useful range of sizes, in a way that could survive photocopying a research paper and still be legible, the world’s serious typographers were probably already using word processors that could render a fixed size, monospaced font on their dot matrix printer with underlining!
TeX’s handling of fonts is archaic by modern standards, of course, though updates like XeTeX do a much better job when it comes to things like OpenType and Unicode. However, in fairness, Knuth developed TeX many years ago, at a time before these modern standards were a glint in their metaphorical parents’ eyes. I think it’s rather unfair to criticise on this basis, and much of what he did has set the standard for three decades.
Getting back on topic, if the person or people behind the tool we’re discussing can do half the job for musical notation that Knuth did for mathematics, it will be a very fine achievement indeed. As with mathematics, it is relatively easy to scribble musical symbols in a way that is technically correct, but rendering music in a way that remains clear and effective even when read at speed in large volumes is quite a different thing. Nitpicking about some of the typography in an early demo seems a little unfair, given the already high standard of the overall rendering.
And there were networks and ways to share documents before the WWW, but look how that's taken off. Being able to do things that used to require expensive, proprietary systems with free, open, standards-based methods is ALWAYS worth hype. You want lightning? Wait until we can do fabulous things on ALL mobile devices with just a good browser and NO additional software from any particular company. "Lightning" happens when millions of people can do something for free that only thousands of paying customers used to be able to do.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
While I certainly applaud the effort to create a music-editing program in an HTML5 app, this is far from "beautifully rendered music notation."
Basically, from the "demo," we can see that he's managed to map music glyphs onto staves. That's barely "music notation," and it certainly isn't "beautiful" yet. As others have pointed out, there doesn't seem to be a lot of attention paid to spacing, sizing, general layout, etc.
I'm not saying it isn't promising, but if music notation were easy to do well, a few applications like Finale and Sibelius wouldn't have a complete lock on the professional market. Lilypond is the only good open-source alternative I know of, but it isn't WYSIWYG, and I don't know of a free WYSIWYG music notation program with high quality output, i.e., the kind that a professional musician would like to use.
Calling this "beautifully rendered music notation" and saying this guy has a "music notation engraver" is sort of like saying that somebody who built a basic text editor that outputs plain text without formatting has created a "publishing application" that "renders beautiful typeset prose."
Beauty :)
As a music copyist for 40+ years, I'd say this may be a cool concept but has dreadful results. There have been hundreds of programs that produced amateur results like this since the early 1980s, and most of them couldn't (and still can't) do basic contemporary notation. That's why ABC notation is also pretty useless. If it can come close to doing this with good character balance and incorporation of graphical elements -- most of which Finale could do 15 years ago and Score could do long before that -- then it's a start.
I love new implementations, but as any professional in any field knows, ultimately it's what you implement that matters.
Dennis
Please back my project! at Kickstarter.
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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.