[LAD] "bleeding edge html5" has interesting Audio APIs
zanga.mail at gmail.com
Sat Nov 19 11:24:57 UTC 2011
2011/11/19 David Robillard <d at drobilla.net>:
> On Fri, 2011-11-18 at 12:01 +0100, Adrian Knoth wrote:
>> On Thu, Nov 17, 2011 at 11:48:28AM -0800, Niels Mayer wrote:
>> > http://kinlan-presentations.appspot.com/bleeding/index.html#42
>> Another step towards "What is an OS? I do everything in the browser."
>> I don't really like it, though I see large-scale advantages when people
>> don't have to install office anymore. ;)
>> > Simple low-latency, glitch-free, audio playback and scheduling
>> > Real-time processing and analysis
>> > Low-level audio manipulation
>> > Effects: spatial panning, low/high pass filters, convolution, gain, ...
>> GUI-wise, using HTML5 sounds sane to me. Definitely for static UI
>> elements, no idea about meters.
>> If they add decent ways to do DSP with it, I don't see a reason why the
>> whole concept shouldn't fly.
> I have every intention of moving as much GUI into the browser as
> possible, FWIW. Whatever isn't good enough now will be soon enough.
> Writing to native toolkits has always been the worst part of programming
> an app, by far the biggest hindrance to true portability, and encourages
> lack of UI/engine separation. I will not miss it one little bit.
> There are things I don't like about it, and I'm sure a large number of
> fellow retro curmudgeons around here feel likewise... but sometimes you
> have to take a look around and acknowledge reality. How many people
> reading this keep a device with a full blown web browser in their
> pocket? When is the last time you used a computer that couldn't display
> a web page? QED.
> Writing one UI that works on all reasonable devices for free with zero
> software installation? Free "remote control" with any PC or tablet or
> phone with wifi? Yes please. Whatever cons there are, they don't even
> come close to trumping that very tangible user-visible win.
> P.S. I specifically mean UI. There may come a day when writing actual
> audio code in whatever the browser runs is not completely insane, but
> that day is not today.
Well... it just happens that I just started a PhD and my research
topic is about writing a new audio programming language. I was already
considering whether to write a NPAPI plugin to be used in conjunction
with the web audio API and having the audio code interpreted inside
the browser in a real-time safe way, but this is not a priority at the
moment. Of course, if there is people interested and/or somebody
provides funding or anything valuable reaserch-wise, things get
However, apart from that, as Dave already knows, I am also
experimenting heavily with HTML/CSS/JS GUIs these days, and sooner or
later I hope to do work on a HTML GUI extension for LV2 plugins.
The least related vapourware-talking I can do now is about two things
I'm currently working on: a minimal layer (< 1k LOC) called "ino"
above Qt/Webkit to write local application GUIs using web technologies
and to do hybrid C/JS programming (no Qt or Webkit APIs are exposed
however), and an LV2 effect rack host called "FreeADSP" whose GUI is
ino-based. Both in heavy development and unreleased as of now, however
if you want to take a look the code is here:
http://hg.atheme.org/naspro/ . The ino library is basically completed
for my current purposes (but still undocumented), while FreeADSP still
misses most of the audio processing part, but already has nice PPM
meters using HTML canvas, if you're interested. :-)
However, the dream would be to combine all the things together: I
mean, if one day we have LV2 plugins whose DSP part can be written in
an interpreted audio language, and we have HTML plugin GUIs for LV2,
and the web audio API starts being supported by most browsers (AFAIK,
only Chrome supports it now), then I think an NPAPI plugin for
"interpreted LV2 plugins" could be an option too (and perhaps even a
Now I go back to the real world. :-P
More information about the Linux-audio-dev