On Thu, Aug 9, 2012 at 1:16 PM, Marcus Geelnard <mage@opera.com> wrote: > Citerar olivier Thereaux <olivier.thereaux@bbc.co.uk>: > > >> On 9 Aug 2012, at 09:40, Mark Boas wrote: >> >> Standards are not about vendors, they are about developers. >>> >> >> Sure. Notwithstanding the requests from developers who want to build >> libraries (useful, but a very specific view of things) the feedback we >> have received from developers seems to be: >> >> * The high-level access provided by the web audio API is great and makes >> it easy to audio processing an analysis code easily, today, with very >> little concern for optimization. >> >> * The moment you want to build anything custom, the API in its current >> state is not great. I recall my team complaining that the moment you want >> to do custom processing, you have to basically wrap everything in your own >> class, and write a lot of boilerplate. [Ping ChrisL/Matt for details.] >> >> The demand is for both, and I suspect this group would benefit from >> having fewer suggestions that we should go for one XOR the other. >> > > Yes, exactly. I think that the debate has been a bit biased towards only > having good support for one of the two (either high level fixed function > nodes or low level custom nodes). I'm in favor of having both. > > The problem, as I see it, is that there has not been enough focus on > fixing the custom nodes. The current set of fixed function nodes is in a > quite mature state (the debate here seems to focus mostly on polishing the > interfaces), but custom processing is not quite there yet. > > I hope that we can have a serious discussion with the starting point of > making custom processing a first class citizen of the Web Audio API, > including identifying ways to make performance and latency as optimal as > possible. If we all conclude that some of the required changes are not > feasible at this point in time, we'll have to settle for something less, > but let's not close the debate prematurely based on assumptions such as > "It's complicated", or "Very few developers will use it anyway". > > Regards, > > Marcus > Hi Marcus, So far, we've been talking about allowing JavaScriptAudioNode to run in a web worker, adding the potential for multiple inputs/outputs, and also potentially adding tighter integration with AudioParam. I know you've also been working on a math library, which looks like something which could be designed in parallel as a general-purpose API and that a JavaScriptAudioNode could call these functions. What are your thoughts here? Chris
Received on Thursday, 9 August 2012 20:31:51 UTC