Posted
by
timothyon Friday May 14, 2010 @08:09AM
from the pretty-printing-for-piano dept.

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."

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.

I think he meant that the library has not external dependencies (and not the demo page).

The jquery dependency is only for the the document.onload handler, and not the actual rendering code. I took out the jquery script tag, and replaced $(...) with document.onload and everything still worked.

... and the proper way to do it to prove that there are no external dependancies would be to create a page that has ONLY the library in question, and a document.onload handler that ONLY calls the library in question.

He's just using loading the jQuery library from Google. The jQuery library is FOSS though (and consists of that single file), he could just as easily store it on his own server and is probably using Google for convenience's sake. I suppose technically jQuery is a dependency, but it's just JavaScript itself and so many people use it that I basically consider it part of the language now.

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).

At 72k for the "minified" version, it's the wrong thing to do if it's not needed. The correct way to demo that a library has no external dependencies is to create a page without anything except that library and a document.onload handler to invoke the test case.

Saying "it doesn't have external dependencies" is not the same thing at all.

This is the exact right thing to do if you plan to use JQuery. Yeah, sure, you could be an idiot and host it yourself (it's an OSS project, after all), but then you're wasting people's bandwidth because their browser has to retrieve your copy, rather than using the copy of Google's that they've cached while browsing websites being run by people who actually know what they're doing. Furthermore, it reduces load on your own server, as if the br

This is the exact right thing to do if you plan to use JQuery. Yeah, sure, you could be an idiot and host it yourself (it's an OSS project, after all), but then you're wasting people's bandwidth

All 24k of it.

websites being run by people who actually know what they're doing.

That, or people who value the privacy of their users, and who would like to not have their website depend on Google being reachable, alive, and trustworthy. Sure, it probably will be, but can you say, "Single Point of Failure"?

Furthermore, it reduces load on your own server

Well, again, by 24k. Is that really worth it?

Now, I can see the appeal. I'm not saying you're automatically a moron for using this. But at the same time, don't assume that the only reason someone wouldn't use Google's APIs is because they don't know what they're doing.

Actually, even the minified version is 72k, not 24k, so it's even worse (I did a wget on that particular version to confirm the size - jquery.min.js 72,174 bytes). And of course the only way to verify that the minified version doesn't pull in more stuff is to look at the browser requests, since the source script is, for all practical purposes, semi-obfuscated.

If the "only" purpose was to run the script, a simple body.onload() would have done the job, as would calling the first function from an embedded sc

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

Looking at the source code, it only uses jQuery for an on page load handler. The library itself doesn't have any references to jQuery or to the '$' context that jQuery uses. He probably could have used a body onload tag to achieve the same thing, but then when pushing new web standards and using methodologies from the early 90's, this was probably the safer path.

I can almost hear the thundering footsteps of developers rushing to HTML 5. I have to admit, I'm one of them.

HTML5 Music NotationVersion 0.1 by 0xfe

Test 1HTML5 Canvas not supported on this browser.Test 2HTML5 Canvas not supported on this browser.Test 3HTML5 Canvas not supported on this browser.Generated completely with JavaScript using the HTML5 "Canvas" tag.

I'm at work and I can see canvas just fine. But maybe that's because my employer intentionally uses a mixture of Chrome, Firefox, and IE, so that office staff can more quickly find and report browser compatibility problems that might also affect the public side of our web site.

The Recording Industry Association of America (RIAA), as its name suggests, deals with recordings. Copying of musical scores falls under the domain of music publishers, entirely separate organizations.

The agency in question is Harry Fox Agency. They represent the majority of music publishers, and were responsible for bringing down the Online Guitar Archive (OLGA) back in the 90's for publishing infringement for posting tablature.

Only sometimes. At least in the contemporary art music world, I've talked to employees of some publishers' who are happy that recordings are so widely shared now, since the more of a fanbase their composers have, the more they get programmed at concerts and thus make the publisher money.

I'd like to see accidentals [wikipedia.org] 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.

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 [maltedmedia.com] 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

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 t

That's how JavaScript library developers get away with describing something as "ONLY 75K TO DOWNLOAD!" They strip out the whitespace (and occasionally use gzip). Makes debugging a royal PITA, to say nothing of the disingenuousness of the claim.

We already have MusicXML [wikipedia.org] and TeX [wikipedia.org]/LilyPond [wikipedia.org] 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.

MusicXML is extremely clunky to work with. TeX is fine as a backend, though fiddly to set up, but for working with...ugh. Lilypond is good, though the learning curve for the basics is really too steep. Another alternative is ABC, which I use a lot. However, more to the point, our hero hasn't settled on a markup language yet - the whole thing is drawn from primitives.

Yes, this is a very nice start and working in academic tech I'm really interested in seeing this sort of stuff moving forwards.

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 [songsterr.com], and nobody calls them incredible. I look at the moving dot demo and then go back to Prezi [prezi.com], or listen to all the stuff about video in HTML 5 and then go work in Kaltura [kaltura.org] 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.

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

Looks like another limited system based on standard notational systems. Nowadays I prefer music automatons that create highly dynamic loops. Stuff that you can build in Reaktor [native-instruments.com], and that you control with lots of MIDI controllers and analog inputs (read: microphone, instruments). My music scores would look like those of Aphex Twin [youtube.com]: http://navid.radiantempire.com/pub/pix/Lustiges/aphex_twin.jpg [radiantempire.com] ^^

The author should know that not ever musician has classical training. In fact the vast majority of us cannot afford to go to music school and pay for classical training. Giving the option to allow us to import any visual composing mechanism we want into the product would be ideal.

It's 2010. Why would we be finding something so simple 'incredible' - oh, wait, it's because people are trying to use the browser to do everything and it's a horrifically bad idea.

Look, I like HTML5, just as I like HTML4, but the web is a terrible programming environment. Javascript is great, but to listen to all the web 2.0/3.0/x.x proponents blather on incessently about how web applications are great and the way of the future and... blah blah blah. It's ridiculous.

For the users, yes, web applications are great, and for some things, they are the way of the future

The idea of Web applications is great, web applications themselves that rely on HTML/XHMTL and JavaScript are awful. Personally, I think the way of the future is purely web services consumed by specialty applications, not what we consider a 'web browser' today, where the HTML aspect of the web (typography/layout) is not the primary medium of the internet - data is, and HTML is merely a subset of that. Thin

I currently work in the field of computer music typesetting, and can vouch for the fact that it is a hard problem - one that is considered not to amenable to being universally automated by computer.

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 [recordare.com], 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.

- 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've been using the OSS "MuseScore" editor, and I'm perfectly happy with the layout (less so about usability).- Javascript is not your first choice. What language would be? I suspect, for the layout part, functional programming would be perfect -- for a programm

This is one of the problems with the freedoms that the computer revolution has given us. Anyone can design a book, or notate a page of music -- but can they do it WELL? Technology is sadly, no substitute for talent.

Music engraving -- on sheets of metal by hand -- had a 9 year apprenticeship. It has been proved that Music notation cannot be represented automatically by algorithms. Most notation programs still require a knowledgeable eye to adjust elements by hand.

This is one of the problems with the freedoms that the computer revolution has given us. Anyone can design a book, or notate a page of music -- but can they do it WELL? Technology is sadly, no substitute for talent.

I'm totally with you on this, but again, the question is how many people care?

I think if you gave them a side by side comparison of LaTeX output vs Word output, most people would see that the LaTeX output was "nicer" for reasons they couldn't put their finger on.

But if you printed a book from Word and gave it to arbitrary people to read, what proportion would say "sorry, this is too ugly and difficult to read"?

The layout of score conveys enormous amount of semantic information about music - for instance, the horizontal position of notes align across the staves of multiple parts if the notes start concurrently. In multi-voice music, stem direction is used to indicate which voice notes belong to, and therefore also implies phrasing. There are many other examples of this kind.

There are also lots of examples where layout improves the usability of score. Some of them are really quite subtle with the results looki

- 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.

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."

Yeah, me too in IE 7. But, that's still a bit old. I'd love to see this, but I guess I'll have to wait until I get home. If it's as good as the summary makes it sound, Coda Music may have a need to be concerned.

IE 9 doesn't support canvas but it does support SVG. you *could* do a an IE 9 version of this demo in svg and i'd argue it would probably look better in svg, but i wouldn't as the lack of canvas tag support feels like ms sending a big fuck you to web devs once again.

Dream? It's not that much a fevered dream any longer, it is closing in on reality, ever since 2007, IE's market share has only gone one way. And with Chrome and Safari in the mix as well, IE's market share won't go up any time soon.

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.

He says he wants an editor before he can release. From the followup post, he says he's going to use ABC notation to actually post scores but leave designing the front end to someone else. Just out of curiosity, I looked at what he's using now, here is the notation to generate the score for the first demo. The first part is just drawing the bars:

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.

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.