- From: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
- Date: Wed, 9 May 2012 05:38:22 +0800
- To: public-audio@w3.org
The "connect AudioNode output to AudioParam" feature is a super neat and welcome addition! On fan-in - Is fan-in up for consideration in the spec? I notice that there is no mention of fan-in in the spec while the node=>param fan-out support is explicit. The WebKit source, though, indicates that fan-in support might be expected (https://bugs.webkit.org/show_bug.cgi?id=83610). For an opinion, not having fan-in for an AudioParam is not a big deal since an AudioGainNode can always be used as a summer if one is needed ... sort of on the "simple things should be simple and complex things should be possible" principle. AudioParam - AudioParam has automation capabilities that are re-use worthy and it appears useful to expose the creation of AudioParams for use in JavascriptAudioNodes so that they can be equal citizens. The "for later version" proposal by Jussi+Chris described in http://www.w3.org/2011/audio/track/issues/6 would nicely complement the new a-rate param support and would also serve as a mechanism for "named inputs" to a JS node, albeit single channel ones. Btw, if I understood it right, the current WebKit implementation is limited by the fact that an AudioParam needs to be *used* in a node for its values to update according to the timeline. Is that design a factor in not adding an AudioParam constructor to, say, AudioContext in the proposal? Best, -Kumar
Received on Tuesday, 8 May 2012 21:40:57 UTC