W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 17388] (audioparam): AudioParam constructor

From: <bugzilla@jessica.w3.org>
Date: Mon, 03 Dec 2012 12:24:19 +0000
To: public-audio@w3.org
Message-ID: <bug-17388-5429-Dy79nouSzo@http.www.w3.org/Bugs/Public/>

Ray Bellis <ray@bellis.me.uk> changed:

           What    |Removed                     |Added
                 CC|                            |ray@bellis.me.uk

--- Comment #7 from Ray Bellis <ray@bellis.me.uk> ---
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.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 3 December 2012 12:24:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC