Re: Resolution to republish MSP as a note

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