- Notifications
You must be signed in to change notification settings - Fork172
Description
The following issue was raised by the W3C TAG as part of theirreview of the Web Audio API
Constructibility & De-sugaring of static methods
The current API defines 26 interfaces:
$ cat webaudio.idl | grep -i interface | cut -d " " -f 2AudioContextOfflineAudioContextOfflineAudioCompletionEventAudioNodeAudioDestinationNodeAudioParamGainNodeDelayNodeAudioBufferAudioBufferSourceNodeMediaElementAudioSourceNodeScriptProcessorNodeAudioProcessingEventPannerNodeAudioListenerConvolverNodeAnalyserNodeChannelSplitterNodeChannelMergerNodeDynamicsCompressorNodeBiquadFilterNodeWaveShaperNodeOscillatorNodePeriodicWaveMediaStreamAudioSourceNodeMediaStreamAudioDestinationNodeOf these, only two are marked constructible:
$ cat webaudio.idl | grep -A 1 -i constructor | grep interface | cut -d " " -f 2AudioContextOfflineAudioContextMost of the types represented by the non-constructable interfacesare visible in the API through normal use. For instance, to get aPannerNode instance a developer currently uses:
var panner = context.createPanner();Wherecontext is an instance ofAudioContext (or one of its subclasses). Prickly questions arise from this arrangement:
- Assuming that the static methods on the
contextare desirable shortcuts for wiring up the context of aNodeinstance to thecontextagainst which it runs,how does that context get set in a way that would allow pure JS objects to describe it? - By what privileged mechanism does the system create instances of these types if they do not have constructors?
- Are these types in any way subclassable? If not, why not?
- If the intent is to mirror other DOM APIs, it's curious to have
create*()methods but no factory (e.g.:createElement("tagname"))
Adding constructors and context-setting methods (or constructor params) for most of the interfaces that lack them would answer #'s 1 and 2 and largely obviate 4. E.g.:
// A possible de-sugaring for createPanner() when ctors are defined:AudioContext.prototype.createPanner=function(){varp=newPannerNode();p.context=this;returnp;};// An alternative that provides the context via the PannerNode ctor:AudioContext.prototype.createPanner=function(){returnnewPannerNode({context:this});};// An alternative that uses a positional context param:AudioContext.prototype.createPanner=function(attributes){returnnewPannerNode(this,attributes);};
Either constructor style allows theseAudioNode types to conceptually be modeled more cleanly as JS objects which could self-host.
Of course, this requires answering the follow-on questions "what happens if the context is invalid, changes, or is never set?", but those are reasonable to ask and their answers don't need to be complicated (certainly not for v1).
An alternative design might locate the constructors on the context directly, but this seems to create as many problems as it solves.
Using the constructor style from the last variant, we can re-work one of the examples from Section 7:
...varcontext=newAudioContext();...functionplaySound(){varoneShotSound=context.createBufferSource();oneShotSound.buffer=dogBarkingBuffer;// Create a filter, panner, and gain node.varlowpass=context.createBiquadFilter();varpanner=context.createPanner();panner.panningModel="equalpower";panner.distanceModel="linear";vargainNode2=context.createGain();// Make connectionsoneShotSound.connect(lowpass);lowpass.connect(panner);panner.connect(gainNode2);gainNode2.connect(compressor);oneShotSound.start(context.currentTime+0.75);}
to:
...varcontext=newAudioContext();...functionplaySound(){varoneShotSound=newBufferSource(context,{buffer:dogBarkingBuffer});// Create a filter, panner, and gain node.varlowpass=newBiquadFilterNode(context);varpanner=newPannerNode(context,{panningModel:"equalpower",distanceModel:"linear"});vargainNode2=newGainNode(context);// Make connectionsoneShotSound.connect(lowpass);lowpass.connect(panner);panner.connect(gainNode2);gainNode2.connect(compressor);oneShotSound.start(context.currentTime+0.75);}