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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388#6) by Ray Bellis on W3C Bugzilla. Mon, 03 Dec 2012 12:24:19 GMT

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.

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.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/134#issuecomment-24244449