RE: Resolution to republish MSP as a note

I'm also in favor of having both.

Best Regards 

James 


-----Original Message-----
From: Marcus Geelnard [mailto:mage@opera.com] 
Sent: Friday, August 10, 2012 4:16 AM
To: olivier Thereaux
Cc: Mark Boas; Jussi Kalliokoski; Wei, James; Chris Rogers; Stéphane Letz; Audio Working Group; Matthew Paradis; Christopher Lowis
Subject: Re: Resolution to republish MSP as a note

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

Received on Thursday, 9 August 2012 23:30:33 UTC