- From: <bugzilla@jessica.w3.org>
- Date: Mon, 03 Dec 2012 12:24:19 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388
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