Re: Aiding early implementations of the web audio API

I welcome this discussion and I agree with the independent
functions/classes and also that we should provide low enough level hooks
right in for the developers, this doesn't necessarily have to be exclusive
of the high-level stuff. In general I feel we should watch out for bloat
and try and establish a minimum viable 'product' as much as that makes
sense in this context.

Whether the cows get lost or not - they should be free to roam! :)

Mark

On Wed, May 23, 2012 at 10:43 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

>
>
> On Wed, May 23, 2012 at 11:17 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>> Den 2012-05-23 01:46:06 skrev Chris Wilson <cwilso@google.com>:
>>
>>
>>  One question - "exposing the behaviour of built-in AudioNodes in a manner
>>> that authors of JavaScriptAudioNodes can harness" sounds like subclassing
>>> those nodes to me, which isn't the same thing as providing only
>>> lower-level libraries (like FFT) and asking developers to do the hook-up
>>> in JS nodes. What's the desire here?
>>>
>>
>> I think the cleanest and most useful approach would be to provide
>> functions/classes independent of the Audio API, so that you can use it in
>> any way you want, including applications other than audio. For instance,
>> compare this to how typed arrays originally emerged from WebGL (it was a
>> requirement for making WebGL work), but has found wide-spread use in many
>> other applications too.
>>
>> /Marcus
>>
>
> My thoughts exactly.
>

Received on Wednesday, 23 May 2012 09:35:22 UTC