Intent to implement and ship: WebAudio AudioNode constructors

[Raymond Toy]

Contact emails

rt...@chromium.org, hong...@chromium.org

Spec

http://webaudio.github.io/web-audio-api/

This is part of the TAG desugaring issue in https://github.com/w3ctag/spec-reviews/blob/master/2013/07/WebAudio.md and https://github.com/WebAudio/web-audio-api/issues/250

Summary

Currently, to construct a WebAudio AudioNode for a context, you use a factory method. For example, if the node is FooNode, the node is created by "context.createFoo(args)", where args depends on the node. This intent allows FooNode to be created via "new FooNode(context, dict)" where "dict" is a dictionary FooOptions that is specific to the node. In general this dictionary contains members for an args that createFoo needs and also supports initializing any attributes of the node. The member names are the same as the attribute names.

The actual changes are in the current spec now, and the individual changes can be found in the issue https://github.com/WebAudio/web-audio-api/issues/696.

Motivation

This fixes part of the TAG issue with constructibility of AudioNodes.

Interoperability and Compatibility Risk

This is a new addition so there is no compatibility risk. We expect all browsers to implement this since it is a part of the spec now and Microsoft and Mozilla were present for the discussions.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

http://crbug.com/626449

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6409704485945344

Requesting approval to ship?

Yes

[Rick Byers]

It would be nice to have some public support from another vendor, but this is a tiny enough ergonomics improvement that I don't think it's worth blocking on.  LGTM1

[Philip Jägenstedt]

LGTM2

Do you intend to keep adding create* methods for future AudioNode interfaces, or is the set of create* methods now frozen?

[Raymond Toy]

I believe we will not add more factory methods.

However, there is a proposal to add a new ConstantSourceNode that will make it into v1 of the spec. Currently, the proposal is to include createConstantSource as well as new ConstantSourceNode. This was mostly for consistency for v1 but it's not decided.

[Raymond Toy]

I can't really speak on what other browsers will do, but Microsoft and Mozilla had representatives at all the meetings and I expect that they eventually implement this.

[Dimitri Glazkov]

LGTM3

[Alex Russell]

I'm glad to see this moving forward. Thanks for being so diligent in getting real constructors into the design, Raymond!

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Raymond Toy]

On Fri, Sep 9, 2016 at 1:56 PM, Alex Russell <sligh...@google.com> wrote:

I'm glad to see this moving forward. Thanks for being so diligent in getting real constructors into the design, Raymond!

I was being a bit selfish. :-) I've always hated the factory methods where you have to say 

node = context.createFoo()

node.a1 = v1;

node.a2 = v2;

node.a3 = v3;

Just give me a constructor so I can just say

new FooNode(context, {a1: v1, a2: v2, a3: v3})

Especially for nodes where there's an ordering consideration like a ConvolverNode that can normalize (or not) the impulse response. (The response is normalized depending on whether you set the flag first or the response buffer first.)