Re: Questioning the current direction of the Web Audio API

> Could you clarify what you mean by "objects"?

Sorry ... I got spoiled by the Pure Data terminology. Understand
"object" as "AudioNode"!

> I think it's fair to say that the Web Audio API targets, at least in the initial "version 1" form common use cases on the web where previously one may have used Flash, plugins or hacks around the <audio> element.

So basically, the enthusiasm was bigger the initial scope if I
understand right :)

> Our Use Cases document gives a good idea of the kind of real-life applications we are targetting https://dvcs.w3.org/hg/audio/raw-file/tip/reqs/Overview.html


Point 2.2 - 3D game with music and convincing sound effects : As I
said in the initial message, this is possible, except for the point 3
"the automated creation of generative music from basic building blocks
or algorithms". With the current objects, the possibilities are in my
opinion too limited to get any interesting result. You would need at
the very least some noise generators.

Point 2.3 - online music production tool : It is pretty much
impossible to implement with current functionalities. Just open a DAW
and check-out the huge list of effects / plugins that you can apply to
your tracks in real-time.

All in all, real-time audio (as used in DAWs or any system to generate
music) is interesting only if people/companies can provide more
functionalities, implement custom synthesis/processing algorithms, ... This
is the reason why existing desktop applications are so good, because
thousands of tinkerers, musicians and scientists have implemented their own
stuff, and I think the current spec really miss this point completely by
trying to force people to use a fixed set of nodes. Which is really really
boring (sorry again!).

To me the ideal Web Audio API, would just stay out of the way, and enable
people to do as much as possible instead of forcing them into a very rigid
framework.

That would be less work on the browser vendors side, and that would really
be a win-win :)


2013/10/18 s p <sebpiq@gmail.com>

> Answer from Chris Lowis :
>
>  Hi Sebastien, Thank you very much for getting in touch, it's great to
> hear from computer musicians and to learn more about your requirements.
> I'll reply in-line here, but perhaps we could continue the discussion as a
> group on public-audio@w3.org?
>
> > ry similar paradigm). It turned out to be pretty much impossible. For a
> simple reason is that Web Audio API really lacks objects, so I would have
> to implement most of them using **ScriptProcessorNodes**, and then loose
> all the benefits of using Web Audio API (all dsp in one ScriptProcessorNode
> would be faster).
>
> Could you clarify what you mean by "objects"? Do you mean node types, and
> in particular one-to-one mapping to existing nodes within PD - or are you
> talking about a JavaScript "object" layer on top of Web Audio?
>
> > The only stab - that I know of - at implementing some serious sound
> programming library on top of other WAA nodes is [waax](
> https://github.com/hoch/waax). But it cruelly lacks objects, and uses a
> couple of [ugly hacks](
> https://github.com/hoch/WAAX/blob/master/src/units/generators/Noise.js#L14
> ).
>
> I could do with a clarification of "objects" again here, just to help
> understand what you mean.
>
> > I love the idea of Web Audio API. But right now I feel that it really
> lacks prespective, and a clear direction.
>
> I think it's fair to say that the Web Audio API targets, at least in the
> initial "version 1" form common use cases on the web where previously one
> may have used Flash, plugins or hacks around the <audio> element. Having
> said that, there has been a large amount of interest from the computer
> music community in the API, and there is certainly a lot of interest in
> developing more in this direction.
>
> > I'd really like to hear people's opinion about why they do it like that,
> how and why they think it can/will be used for real-life applications,
> because the goals stated in the draft are - in my humble opinion -
> completely unrealistic with the current functionalities.
>
> Our Use Cases document gives a good idea of the kind of real-life
> applications we are targetting:
> https://dvcs.w3.org/hg/audio/raw-file/tip/reqs/Overview.html
>
> > I am sorry to be a bit harsh, and question this project in its
> foundations, but I suppose that's what you get for being implied in open
> standards : any random angry guy out there can come and complain :)
>
> Not at all, speaking personally I think what you are doing is fascinating
> and something I hope more people will attempt using the API in the future.
> Please keep the discussion going! Cheers, Chris
>



-- 
*Sébastien Piquemal
*
*
** *-----* @sebpiq*
 -----* *http://github.com/sebpiq*
*
 ----- http://funktion.fm