VJ Heaven

A quick view into Ableton’s browsers, instruments and enabling plugins.

Nuovo smartphone Android htc Desire, principali caratteristiche e confronto. Maggiori info su Android.HDblog.it, htc.HDblog.it o Hdblog.it

Phil takes a look at the Dolphin Browser HD on Android.

The native WebKit browser lets users experience the “full web” and easily move between browsing and other tasks on their phone.

Is the Froyo web browser really significantly faster than anything else out there? Let’s find out! To get Froyo: bit.ly and bit.ly

One thing I like about Android… browser tricks. Watch Android team members talk about their favorite features.

“The hills are alive /
with the sound of browsers”

Ever thought you’d make sounds in a browser, or have new ways of visualizing music playback? It’s happening, with builds of Firefox anyone can download.

Work to make browsers rich with sound synthesis and visualization continues. “Compatibility” isn’t really an advantage yet, because Firefox is the only browser with support, and only in the next version, though that could change in the future. And yes, Flash is capable of some of this, too (though not real 3D), with 90-95% saturation, conservatively, of computers. But if not compatibility, what these experiments do represent is what happens when someone working on a tool (Firefox, in this case) really commits to making sound a priority, and supporting free standards and developer tools (an emerging standard API, WebGL, Processing.js, etc.).

In fact, it’d be great if this occurred everywhere: if you’re making a platform, make sound a priority, and people will do mind-blowing stuff with your platform.

Among the latest fruits:

1. 3D eye candy. Charles Cliffe has a psychedelic visualization of sound playback. The JavaScript nuts are also proceeding to do more things with their language than most would deem possible, even moving DSP calculations to JavaScript code. I remain a bit skeptical there: the question to me isn’t whether JavaScript is “fast enough,” but whether native code is faster or simply the better tool for some jobs. Details below.

2. Patching in a browser – with a Pd clone. Chris McCormick is porting a subset of basic Pd objects to the browser. Now, one side of me wonders whether Pd is the best choice; it’s a somewhat idiosyncratic, if powerful, language for describing sound patching. But on the other hand, I could see this being fantastic in teaching and sharing: put basic patches up in a browser, let people play with them live, then build more advanced tools (with greater hardware access and external support than is possible in a browse) in the traditional Pd tool. As I keep saying, I think there’s far too much partisanship in the discussion (“Browsers for everything!” / “Browsers are useless!”), far too little thinking about how the browser and the desktop tool are more powerful together.

Web Audio Data API – Pure Data and Processing.js from David Humphrey on Vimeo.

Check out:
mccormick.cx/dev/webpd/
wiki.mozilla.org/Audio_Data_API

Also — heck, I may try this out in workshops as soon as next week. The browser could build a basic language for music and visuals in Processing and Pd, then robust performance tools could be built in the native tools, with quite a lot of compatibility between the two.

3. Actual standards. The W3C, the standards body behind HTML, has added this discussion to an Audio Incubator group. (It’s been incubating for some time, but maybe this will help something actually hatch.) Now I’d just like to see these things in Chrome/Chromium, too – I wonder if anyone’s up to a test build, as the standards adoption discussion continues. A number of readers have pointed out that MPEG4 had a specification that included, wholesale evidently, Csound. But this process seems more organic to me – you need actual tools and real-world experiments to evaluate the validity of something, not just standards on paper.

Putting the Awesomeness in Context: An Appeal

A side rant, though: why do Web geeks only care about what happens in the browser? It’s funny to me it seems that outlets like Slashdot jump on stories like browser-based tools, but ignore exactly the same ideas if they’re in a separate app. That’s not a criticism of the Mozilla crew or these brilliant hackers – this is what development is all about, pushing your tools to the limits. But if there isn’t a broader recognition of the value of what you’re doing or why you’re doing it in the first place, there’s a danger that unsustainable tool fetish will miss the point. That is, synthesis in the browser is excellent, but if people don’t understand the value of the synthesis itself, we have a lot more work to do.

Even the tools themselves need a context. It also JavaScript is amazing, but so are tools in Python, Java, Scala, and so on… and some of the enduring power of C still shows here. Browser powers are cool, but the OS is just as important – performance of Firefox would be heavily dependent on support for OS-native, low-latency audio outputs, like JACK on Linux. (Yes, it’s open source, so you can go do it yourself. No, I have no idea how to build Firefox for JACK – maybe a reader does?)

I’ve still yet to see a compelling explanation of what the browser really is, and what’s possible with its interface paradigm. That should be a fascinating discussion, actually, especially with the radical transformation of the browser, particularly as players like Google make it the central aspect of TV-watching or tablet experiences. But the discussion is only really interesting if you don’t start out with the value as a given. For instance, if browsers become a bigger part of what we do, is its simplistic tab metaphor really sufficient? If browsers simply bundle a set of native tools, are there ways “standalone” apps might adopt similar, standards-based approaches?

David Humphrey argues that part of the value here is the view source concept, but the Web has had the same empowering influence on sharing, collaboration, and reuse with platforms other than just JavaScript. The browser itself is a largely misunderstood piece of technology, partly because users (understandably) focus on their experience, and doesn’t pay attention to which aspects are delivered by the browser, the OS, or some other piece of code.

Oh, side note: this isn’t about “the cloud.” The cool stuff here is happening on your local hardware, period. That’s what makes it fast, and that’s what makes it work for audio, and your local machine is getting cheaper, cooler, and less power-hungry all the time. New DSP and floating-point capabilities in devices like tablets could make sound more powerful and flexible than ever before – provided people work out how to maximize, not squander, those capabilities.

So, here’s what I’d like to ask: what form will the standards discussion take? And how can these larger discussions – many of which transcend the discussion of any one tool or standard – find a forum?

Behind the Scenes, More Info

While you ponder that (and I’m open to suggestions), here’s more reading for you:
Experiments with audio, part X [Dave Humphrey's increasingly-awesome blog]

Previously:
Real Sound Synthesis, Now in the Browser; Possible New Standard?

More details on the first example, and how it was built (Minefield is Firefox 3.7):

All runs in real-time with Javascript, WebGL and HTML5 only (uses Minefield Audio build) — no browser plugins are used.

This demo combines the CubicVR 3D engine on WebGL (www.cubicvr.org) with the Mozilla HTML5 Audio API (hacks.mozilla.org), Processing.js (www.processingjs.org) and BeatDetektor.js (www.beatdetektor.com)

Mozilla Audio API is used to sample the HTML5 audio tag on the page, this information is processed by BeatDetektor.js which produces timing information for the Processing.js real-time canvas textures and the CubicVR.js procedurally generated WebGL scene using them.

The camera is set to free roam a simple chase pattern with a probability to follow a nearby cube (fully automated).

Available online at:

http://cubicvr.org/CubicVR.js/bd3/BeatDetektor3HD.html

or if you have a Float32Array enabled Minefield build:

http://cubicvr.org/CubicVR.js/bd3/Bea…

you can find more info about audio api-enabled Minefield builds at:

https://wiki.mozilla.org/Audio_Data_API

You can also feel free to chat with us about the Audio API via the #audio channel on irc.mozilla.org

Enjoy! And yes, I’ll have to work out a more beginner-friendly, here’s how to do this post.

View full post on Create Digital Music

Music scores remain one of the best ways to record or share many musical ideas. If you’ve done even casual notation, you’ve likely had the experience of scrawling something down on a scrap piece of paper, manuscript or otherwise.

Imagine, instead, quickly scrawling something in the now-ubiquitous web browser window.

Gregory Dyke writes with a notation project he’s built with Paul Rosen; he says that it’s further along in its development than the notation project we saw last week. As before, it employs JavaScript and HTML5, and the Canvas element SVG support, rendering quickly in any modern browser right inside a web page. (Correction: it’s SVG, not Canvas, that makes this work, thanks to the raphaeljs library.)

Abcjs is an open source parsing and rendering tool for ABC written entirely in javascript, so it allows sheet music to be rendered as both standard notation and MIDI entirely with the browser.

Here are a couple ways to use this:

For rendering any ABC notation found on a web page as standard notation,
see http://drawthedots.com/abcjs

For a free on-line editor and tune storage website, see
http://drawthedots.com

Enjoy! And we’d appreciate feedback of all kinds.

Notes:
1) ABC 1.6 is mostly done, and many parts of ABC 2.0 are supported. We are actively working on improving the rendering.

2) We know that the rendering in IE is not as pretty as Firefox, Safari, and Chrome, but we’re working it!

Here, the ABC notation format is a standard, so you can simply type in or copy and paste any ABC-encoded text and render it right away.

It looks ideal for dropping musical excerpts or examples into a page, but this project even in its early stage offers another idea: why not quickly type in your notes in simple text characters, then store and share that score with others? There’s even instant music rendering.

Simple, lightweight examples do have a way of opening the door to more technically-involved discussions, and this is no exception.

ABC is nifty and easy, but it isn’t capable of representing more sophisticated scores in the way that the free Lilypond format is. I noted last week that Lilypond is nonetheless readable and easy for basic entry, even as it adds sophisticated features with a little more work. I think even having a web window with ABC is nice enough, and it should be possible to go from the simpler format (ABC) to other, more complex formats (MusicXML or Lilypond). But this question of how to interchange files remains one of interest. After the post last week, the project we saw spawned a long discussion in its blog’s comments on how interchange might work. Greg, for his part, concedes that “abc is quite powerful, but stops at complex multivoice scores where voices move across staves (simple multivoice and multistave is possible).” That could make putting Lilypond in the browser a useful activity, and since it is possible to go from MusicXML to Lilypond, it should enable MusicXML, as well.

As with sound synthesis, putting notation in the browser demonstrates how both the “desktop” app and the “browser” app can differentiate themselves. The browser focuses on quick, simple entry and sharing. The desktop app remains the tool for connecting to MIDI hardware, performing more sophisticated entry and layout, and project management. Far from competing, each gives the other greater purpose and a clearer sense of how the two design approaches can differ. Because a Web rendering engine like WebKit is also embeddable, the line doesn’t even need to be absolutely clear. I can imagine, for instance, Lilypond editors that use WebKit for lower-quality, real-time notation previews, prior to doing a full Lilypond render in PDF. (There are real-time PDF rendering libraries like Cairo, too, so I have no idea whether that makes sense, but the array of options open to developers is nonetheless expanded.)

The project is free and open, so let us know if you modify it somehow. (JavaScript-controlled, 3D-produced generative scores, perhaps?)

http://code.google.com/p/abcjs/

Updated: Gregory replies with an email, and it was useful enough to me that I’m reprinting it in full. He notes most importantly that ABCjs is capable of more sophisticated rendering than seen here, even if it doesn’t yet do as much as, say, the Lilypond renderer does.

Thanks a lot. You’re spot on with the note taking idea – I wonder whether this would be a good way to create a mobile browser app – still runs a bit slow on mobile safari though – about 8seconds for rendering on my 3g. Nice to see you discuss abcjs as a full blog post.

Just a note: we don’t use canvas, but svg, using raphaeljs to bridge across browsers.

In hindsight, we should probably put a more sophisticated example on the landing page. For example, the tunes below render quite nicely (although not with complete midi playback). We should probably finds ourselves a demo score which runs the whole gamut of several voices, ornamentation, chords, guitar chords, dynamics, etc.

Thanks again for the heads up

Greg

X:3
T: TEST: Erev Ba % —
C: from Israel
M: C|
L: 1/4
K:G
V:1
“G”dgf g/b/ | “Am”a3z | “D7″ab c’/d’/ b | “G”b3z | dgf g/b/ | “Am”a3z |
“D7″ab c’/d’/ b | “B7″b3z | “C”ceg>g | f/g/f/e/ e2 | “Am”Ace>e | “D”d>c B/A/G/F/ |
“Em”G2 E2 | “Am”A2 “D7″A/B/ G | (“G”G4|G2) z2 | dgf g/b/ | “Am”a3z |
“D7″ab c’/d’/ b | “G”b3z | dgf g/b/ | “Am”a3z | “D7″ab c’/d’/ b | “B7″b3z |
“C”ceg>g | f/g/ f/e/ e2 | “Am”Ace>e | “D”d>c B/A/G/F/ | “Em”G2 E2 | “Am”A2 “D7″A/B/ G |
“G”G>A B c/A/ | “G7″d>e =f/d/B/A/ [K:C] ||”C”G2z2| “Dm7″d/e/f/e/ d/c/B/A/ |\
“G7″G2z2 | “C”z/ G/c/B/ c/d/e/f/ |
g g/a/ g2 | “Dm7″f/g/a/g/ f/e/d/c/ | “G7″B/c/d/c/ B/A/ G| “E”^G>B e/d/c/B/|\
“F”c2 a>a | g/a/g/f/ .f .e |
“Dm”d2f>f | “G”e>d c/B/A/B/ | “Am”c/d/c/B/ A/G/F/E/ | “Dm”D/E/F/D/ “G7″G A/B/ |\
“C”c3 e| .g.a.g e/d/ |
GcBc/e/ | “Dm7″d3z | “G7″def/g/e| “C”e3z | GcBc/e/ | “Dm7″d3z |
“G7″def/g/e| “E”e3z | “F”FAc>c| B/c/B/A/ A2| “Dm”DFA>A| “G”G>F E/D/C/E/ |
“Am”c2A2 | “Dm”d2 “G7″d/e/c | (“C”c4|”Dm”c2) “G7″d/e/c| (“C”c4| c2) z2 |]
%
V:2 gch=0
“G”z4 | “Am”z4 | “D7″z4 | “G”z4 | z4 | “Am”z4 |
“D7″z4 | “B7″z4 | “C”z4 | z4 | “Am”z4 | “D”z4 |
“Em”G2Bd | “Am”c2 “D7″c/d/ B | “G”B>ABd | B>A G/A/ B| d2 z2 | “Am”A/B/c/B/ A/G/F/E/ |
“D7″D2 z2 | “G”z/D/G/F/ G/A/B/c/ | d d/e/ d2| “Am”c/d/e/d/ c/B/A/G/ |\
“D7″F/G/A/G/ F/E/D/C/ | “B7″^D/B,/D/F/ B/A/G/F/ |
“C”c2 e>e | d/e/d/c/ cB| “Am”A2 c>c| “D”B>A G/F/E/F/ |\
“Em”G/A/G/F/ E/D/C/E/ | “Am”A/B/c/^c/ “D7″d e/f/ |
(“G”g4|”G7″g2)z2 [K:C] || “C”GcB c/e/ | “Dm7″d3z | “G7″de f/g/ e| “C”e3z |
GcB c/e/ | “Dm7″d3z | “G7″de f/g/ e| “E”e3z | “F”FAc>c | B/c/B/A/ Az |
“Dm”DFA>A | “G”G>F E/D/C/D/ | “Am”c2 A2 | “Dm”d2 “G7″d/e/c | (“C”c4|c2) z2 |
Gede/g/ | “Dm7″f>e f/e/d/c/ | “G7″Bcd/e/c| “C”c c/B/ c/B/c/d/ |\
e e/f/ ee | “Dm7″f>e f/e/d/c/ |
“G7″Bc d/e/ c | “E”B>A ^G/A/B/G/ | “F”F2 A2 | c2 FE | “Dm”D2 F2 | “G”B2 e2|
“Am”e2c2 | “Dm”f2 “G7″f/g/ e | (“C”e4| “Dm”e2) “G7″f/g/ e | (“C”e4|e2) z2 |]

The mobile question is especially interesting to me; it may be that you need non-JavaScript, “native” SVG libraries, but porting that shouldn’t be impossible either way. I’d love to have a mobile Android sketchpad, especially since my Droid has a keyboard. I’ll look into some testing.

View full post on Create Digital Music

The march of “because you can” experiments with the new generation of Web browsers continues. Last week, we saw real-time synthesis in the browser from a team at Mozilla. Next up: music notation.

Mohit Muthanna has executed a gorgeous example of musical notation using HTML5’s Canvas. (The Canvas is a new feature of the Web standard that makes drawing to the display directly in the browser more functional than in the past.) JavaScript code is translated directly to “engraved” notation on the screen, without any other dependencies, plug-ins, or intermediate libraries.

Music Notation with HTML5 Canvas

This isn’t just using browsers for the sake of it, however; music notation is an important language for sharing musical ideas. Back when I was a freelance educator for Sibelius, a popular feature was that program’s pioneering “export to Web” function. Sibelius’ feature even allowed commerce and other features, but it also meant the need to install a plug-in.

Mohit’s work is a project that spanned “a few weekends.” That’s some of the beauty of the current age of development: you can scratch together a prototype quickly, so that you do something rather than just talk about it. Once a prototype is available, visible, and tangible, it’s sure to lead to deeper discussions about the “right” way to do something, which is the primary reason for creating prototypes in the first place.

Accordingly, the demo of the technology isn’t any more interesting than the comments that follow. As they should, observers immediately wonder about how standard interchange formats could aid in exchanging scores.

So, what are the common interchange formats for notated music? Glad you asked. Some front runners:

Lilypond is mentioned most in comments, because it’s a rich, human-readable format so simple you can comfortably edit it directly in a text editor, it’s a standard format, and it’s the only format here that has an accompanying engraving standard. That is, a common, open-source renderer will immediately turn your score into printed notation. Most formats (like a Word DOC for instance) depend on different apps to be rendered and used; Lilypond is both the format and the standard renderer, and both are free.

MusicXML:Perhaps the most sophisticated of these formats, MusicXML is a royalty-free standard supported by virtually everything on the planet, including, notably, Lilypond itself. MusicXML is the most common way of interchanging with tools like Sibelius and Finale (and many more obscure options).

Abc notation is a very simple language for encoding notation as ASCII. What’s nice about it is that it’s very compact. It can also interchange with formats like Lilypond.

Those are the three that interest me the most. There are others, I’m sure; feel free to bring them up in comments. (Fair warning: I could go on various rants about how complex and inscrutable some of the TeX-based formats are.)

A follow-up post engages the format and interchange issue. SVG support appears to be a definite.
A Question of Formats

Side note: I disagree with the idea that Lilypond is a “TeX-based format” that fails to be “accessible to non-geeks.” I’m not a “non-geek,” but I’m enough of a geek that I have no time, and accessibility is really important to me. Lilypond I find to be eminently readable and concise, usable by hand in a way that TeX is not. There’s no need to attach the stigma of one to the other. ABC is too informal to handle anything beyond simple scores, though it might be just fine for the browser context. I do agree with the MusicXML complaint, though: it works well with these software packages, but it’s not something you’d want to actually use directly.

You may notice that there are richer, freer, easier means of exchanging notation files than there are, say, multitrack music project files. You can thank centuries of music notational tradition for that – the original “standard” before anyone used such things. (“Paper: the original browser!”)

I realize I have to put some disclaimers on any mention of browser standards, lest people think I’m joining the hyperbolic “let’s move everything to the browser” movement. That’s not the point. The idea is, if you can have a standard means of representing something like a score, and you can standardize mechanisms for displaying it in current-generation browsers without the need for plug-ins, exchanging ideas becomes easier. That doesn’t compete with the idea of “native” clients on your desktop. On the contrary, standardizing on a format like Lilypond has made those clients smarter, easier to work with, and more compatible with one another. The browser is itself a bundle of native code, dependent on the desktop operating system to work, and making use of that OS’ facilities for everything from typography to sound.

As with the synthesis last week, something as essential to musical expression as notation is a perfect example of how those facilities evolve. There is no real difference between doing something “on the desktop” and “in the browser.” As these formats demonstrate, though, there’s a big, big difference between doing something with a standard, with the ability to exchange material and remain compatible, instead of having a bunch of isolated software packages that can’t communicate with each other.

I hope some readers here who are experienced both with technology and notation will suggest some ideas for how these tools can continue to evolve and interoperate.

View full post on Create Digital Music

Bloop HTML5 Instrument inspired by Brian Eno’s Bloom from Bocoup on Vimeo.

HTML5 and Javascript Synthesizer from Corban Brook on Vimeo.

Pioneers like Max Mathews’ Bell Labs team taught the computer to hum, sing, and speak, before even the development of primitive graphical user interfaces. So it’s fitting that the standards that chart the Web’s future would again turn to the basics of electronic sound synthesis.

A group of intrepid hackers and Mozilla developers and community leaders are working to make an audio API a standard part of this generation of Web browsers. (Note: not some unspecified future browsers – they’re making it work right now.)

We’ve already seen some pretty amazing experiments with Flash and Java. This would go further, opening buffer-level access to new, faster, just-in-time compiled JavaScript engines. The upshot: you get to code your own synthesizers and real-time audio processing in a way that works right in any browser, on any platform. Standardize the API by which this works, and adding an FM synth to a page could be as easy as assembling a table or inserting a picture.

There’s no plug-in, and thanks to faster JavaScript engines, JavaScript can be the language. To the end user, you just get a Web page that automatically loads the audio goodness.

I’m in touch with the developers, and hope to have a full-blown Q&A session with them. On the agenda: what this is, what it means, how it works, how people can get involved, and how to get started with these early builds. I’m going to start out with some of my own thoughts, though, because I’ve found myself thinking about this a lot. I’ve been a slow convert to the gospel of the browser and JavaScript, but I’m beginning to “get” it, I think. (If I’m off-base or missing something, we’ll get to cover that, too.)

HTML5 3D FFT Visualization with CubicVR from Bocoup on Vimeo.

To understand why this is incredibly cool, though, I think it’s first necessary to understand how incredibly stupid, primitive, and backwards a Web browser is. (I just lost a bunch of Web developers. No offense – there’s a reason it’s that way – but follow with me.)

I’m serious. The Web concept was rooted in an age in which bandwidth and computing restrictions constrained online communication to text. But even as the Web was first catching on, computers themselves had rich multimedia capabilities far exceeding what the browser could do. Today, a lot of Web nuts talk about how the browser could replace desktop applications, or become an “operating system.” But the browser is another application running on your hardware, running on your operating system. The question you might well ask is, why is the browser so limited? Why can’t it do the things the rest of your computer can? The idea that having a tag that specified playing audio or video took until now is kind of silly if you think of it that way, right? (You might ask the inverse question of the “desktop” apps: you do know you’re connected to the Internet, right?)

The idea of the audio API would be to change that, and not only play back sound files, but open up real-time synthesis and processing in standard, accessible-everywhere ways. You can, as you see in the (working, real, not-mock-up) examples, do all kinds of powerful magic. You can visualize music as you play sound files, or perform on instruments right from the browser window.

It’s one thing to talk about some distant future. Fortunately, you don’t have to wait. The code is working right now. You can finish reading this post and then grab a nightly build of Firefox, write a few lines of JavaScript code, and build a synth in the browser.

“Because it’s there” is usually a good enough reason to start hacking. But to musicians, I think there are actual creative benefits, too.

Endless compatibility. The work the Mozilla crowd are doing is already free to download on Mac, Windows, and Linux, stripping platform barriers across desktops, laptops, and netbooks. We’ve heard a lot from certain Mac advocates in particular about how you can only have “first-class” applications if they’re built for a specific OS. That’s fine – depending on the application. But as an artist, at some point I also want some shared tools. If I want to collaborate with someone, they’re what’s first class to me. There’s nothing worse than saying “oh, uh, I guess you have a Mac and I have a PC, so we have to…” It’s creativity-killing. Having browser-based tools on par with the tools outside the browser means we can keep our idiosyncratic tools of choice, but also have a shared set of tools we can access without so much as running an installer, let alone worrying about an OS, processor, or version.

Connectivity and sharing. Being in the browser means instant access to a musical application from anywhere, and instant data for that application. Right now, part of the reason computer musicians have a stigma of staring at computer screens is because the user interfaces we design live on individual machines and are designed to be used only by one person at a time. The connectivity in the browser means it’s easier to build sharing and collaboration directly into a software idea.

Browsers could make your “desktop” apps cooler. One of the myths of browser-based applications I think is the idea that they’ll somehow replace other applications. On the contrary: they could make your existing applications smarter. Unrelated to this particular effort, our friend Andrew Turley built a proof-of-concept application that connects a Web browser as a controller to other apps over OSC. With a little refinement, a free local Web server combined with a browser-based controller app could connect all your traditional music apps to computers in the same room or across the world.

In-browser Synthesizer and Sequencer with Envelope and Filter control from Corban Brook on Vimeo.

The power to make noise – any noise – and a tinkerer’s sunrise. Noise often appeals to hackers (even non-technologist hackers) more than anything else, and that should give you hope. One interpretation of current technology trends runs with the idea that tinkering is in danger, or even on the decline. I think we should be wary of some of those trends; some are simply anti-intellectualism in disguise. I also think tinkering with sound has a bright future. So long as there is raw buffer access somewhere, it’s possible to build something that makes sounds on a level as high as “give me a middle C” or as low level as “I want to invent a new form of synthesis.”

This isn’t just for propellerhead types. With readable code, even those new to programming and sound have an opportunity to start toying with their own experiments. And unlike almost any other medium, sound is both immediate and always satisfying. That is, even if you make some sort of ugly splat, you may still have a good time. That quality makes it perfect for learning and experimentation, whether you’re young or old.

From Babel to common code languages. I’ll also go out on a limb and say there’s potential to get more tools speaking the same language. On the visual side, right now, you can directly copy code from Processing.js (where anyone can easily see it) to a Java-based desktop Processing (where you get higher performance, full-screen and multi-monitor display, hardware access, and the like), often without changing a line of code. The same could happen here. People are already porting Csound examples to this freshly-minted audio API.

Nihilogic’s HTML5 Audio-Data Visualizations from Bocoup on Vimeo.

Open standards, open 3D. By making a standard, too, we have a lingua franca both technologically and in how tools can run. If it were only audio, that’d already be useful. But this extends to other efforts, like the work on WebGL. And WebGL is a good indicator, too: by supporting OpenGL ES 2.0 in the browser, both the “native” or “desktop” app and the “browser” app can share code and capabilities. The same could begin to be true for audio.

Anyway, enough of my third-party sense of what this could mean. Here’s where to go learn more:

David Humphrey is a man you can thank for making this happen. Check out his blog, and read in particular:
Experiments with audio, part IX

May 12 in Boston, there’s a “future of Web audio” event introducing these ideas, if you’re in the area. I’ll see if we can’t get events elsewhere. (This would be ideal for another CDM online global hackday – more so than our previous topic.)

The big post to read:

Alistair MacDonald covers the thinking, the potential applications, the history, and what’s happening now:
Web Audio – All Aboard!

And see:

http://wiki.mozilla.org/Audio_Data_API

Alistair sums up why this important:

A web browser that allows for such fine granular control over video graphics using tools like Canvas and WebGL, yet provides no equivelent control over audio data, is a web browser that is very lopsided. In human terms, web browsers have always been very lopsided. They reflect a specialized facet of ‘the human requirement’. This is unfortunate as the web can potentially encompass a far more balanced and expressive set of features, encapsulating our humanity. Fortunately the modern movement towards a more human browser, appears to have gained significant velocity… in the right direction.

Or, if the Muppet Animal were writing this, I think that would go more like:

NOISE…. MAKE NOISE. LOUD NOISE. MAKE LOUD NOISE.

More HTML5 Goodness

On CDMotion, spectacular 3D graphics, even for the lazy, plus Processing.js resources.

And perhaps more generally useful – especially for working with the 1,000,000 iPads Apple has just sold – Chris Randall has a brilliant and detailed post on hacking the SoundCloud player so it works even when Flash isn’t installed.
Something Wicked This Way Comes…
Or, I should say, by “brilliant,” it points out just how screwed up that particular situation is. So, SoundCloud developers, go read that and report back, okay? (I’ll be in Berlin in three weeks. We can all get some coffees and put together a generic solution that works everywhere. How about that?)

View full post on Create Digital Music