Re: AudioParam namespace in AudioWorkerNode

Sounds like an excellent idea that I should have considered.  I made this
change in the proposal hosted on cwilso.github.io/web-audio-api.


On Mon, Aug 25, 2014 at 2:16 PM, Joseph Berkovitz <joe@noteflight.com>
wrote:

> Chris,
>
> One further piece of feedback, breaking out into a separate thread here.
>
> To keep the parameter namespace clean, I think the dynamic AudioParams
> should be bound to properties of a separate “params” object hanging off of
> AudioProcessingEvent, rather than properties of the event itself.
>
> 1. This prevents any possible collision between parameter names and other
> event properties, of which there are many (and perhaps more in the future).
>
> 2. It also makes it much easier for application code to enumerate the
> AudioParams associated with a given event instance; no need to skip over
> the “builtin” properties of an Event as one iterates.
>
> So:
>
> interface AudioProcessingEvent : Event
>  {
>     readonly    attribute double      playbackTime;
>     readonly    attribute AudioBuffer inputBuffer;
>     readonly    attribute AudioBuffer outputBuffer;
>     readonly    attribute object params;        *// dynamic parameters
> hang off this object*
> };
>
> Thoughts?
>
> …Joe
>