[Bug 17388] (audioparam): AudioParam constructor

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388

--- Comment #8 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #7)
> 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);
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 3 December 2012 18:03:24 UTC