W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: [web-audio-api] (audioparam): AudioParam constructor (#134)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:52 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/134/24244457@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388#7) by Jussi Kalliokoski on W3C Bugzilla. Mon, 03 Dec 2012 18:03:20 GMT

(In reply to [comment #7](#issuecomment-24244449))
> I have an alternate proposal.
> We probably don't really need the ability to directly instantiate a
> standalone AudioParam, we just need to allow a ScriptProcessorNode to own
> them, hence we could ask for them in the ScriptProcessorNode factory call:
>     partial interface AudioContext {
>         ScriptProcessorNode createScriptProcessor(unsigned long bufferSize,
>             optional unsigned long numberOfInputChannels = 2,
>             optional unsigned long numberOfOutputChannels = 2,
>             optional unsigned long numberOfAudioParams = 0         // new
>          );
>     }
> As far as I can see the AudioParam minValue, maxValue and units fields are
> all informational, so I've ignored them.
> The ScriptProcessorNode does of course need to be expose these AudioParams
> so they can receive connections:
>     partial interface ScriptProcessorNode {
>         readonly attribute AudioParam param[];
>     };
> IMHO there's no need for direct name support - the developer can add a
> read-only named attribute that references the appropriate index into the
> param[] array if it's needed.

I like the idea of having anonymous AudioParams, it does indeed simplify things.

> Rather than the "getParamValues()" value suggested above, I believe it
> should be possible to pre-calculate the animation curves and pass their
> values directly as part of the AudioProcessingEvent interface just as
> inputBuffer data is now:
>     partial interface AudioProcessingEvent {
>         readonly attribute AudioBuffer paramBuffer[];
>     };
> I believe the advantage of this approach is that it would simplify usage
> with WebWorkers - all of the required data is passed in one go.

I'm not sure what you're after with this part. Your suggestion has no way of differentiating between k-rate and a-rate parameter inputs, which has implications on performance. I think that we should just change the previous proposal a bit to accommodate:

partial interface AudioProcessingEvent {
    void getParamValues(uint index, Float32Array values);
    float getParamValue(uint index);

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:35:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:11 UTC