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

> [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:
https://github.com/WebAudio/web-audio-api/issues/134#issuecomment-24244457