- From: Colin Clark <colinbdclark@gmail.com>
- Date: Wed, 23 May 2012 22:45:49 -0400
- To: Chris Wilson <cwilso@google.com>
- Cc: robert@ocallahan.org, Chris Rogers <crogers@google.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Marcus Geelnard <mage@opera.com>, public-audio@w3.org, Alistair MacDonald <al@signedon.com>
Hi Chris, On 2012-05-22, at 7:46 PM, Chris Wilson wrote: > 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 Robert and Jussi are suggesting not to have the native nodes; Colin seems to be saying "just make sure you can utilize the underlying bits in JSNode". Is that appropriate? I'm not particularly interested in the notion of subclassing existing AudioNodes, but rather, as you say, having the "underlying bits" also available to JavaScript nodes. If there are established algorithms that can't be implemented in a performant manner without native code, those should be exposed as reusable primitives for the benefit of JS-level authors. So, in other words, to offer a common foundation on which both spec-level AudioNodes and JavaScriptAudioNodes can be built. Colin
Received on Thursday, 24 May 2012 02:46:22 UTC