W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2016

Re: AudioWorklet examples

From: Joe Berkovitz <joe@noteflight.com>
Date: Fri, 29 Apr 2016 08:00:09 -0400
Message-ID: <CA+ojG-b8aZkfEFQbPnFCz8631i=JZAT8cXcr=Wztd0_EvehCOg@mail.gmail.com>
To: Hongchan Choi <hongchan@google.com>
Cc: Raymond Toy <rtoy@google.com>, Audio Working Group <public-audio@w3.org>
Hi Hongchan,

I'm very happy for you to keep the task -- I'm only agitating for it to
happen, not to take it over (unless that's helpful somehow). I'm all for
waiting for things to settle down, that seems like a good idea. I was not
sure where things were left at the F2F but it sounds like this action item
didn't change.

A few opinions on the items you mentioned -- but only chair-hat-off
opinions! -- follow:

- Static resource loading: I've been sitting on this idea for a while, but
> I am inclined to punt this to V2.

I think that that would be fine if we don't find a nice way to do it.

> - AudioParam initialization: I think we're getting close on this one, but
> I heard TC39 is planning to introduce 'static property' in class syntax, so
> I want to check it out.

I'm a little unsure about static properties being the way to go here. One
of the advantages of using a function to define params is that AudioParam
descriptors could be accumulated across the inheritance chain by
concatenating arrays, or some such. If class FooNodeProcessor (or whatever
we're calling these things now) has a parameter "foo", then a subclass
FooBarNodeProcessor might want to add a parameter "bar" to whatever its
superclass is defining.

- Multiple node definitions in a single file: this allows developers to use
> a hacky way of inter-node communication by sharing an object.

I don't see how this can be disallowed at the same time that we allow nodes
to share read-only data.

Received on Friday, 29 April 2016 12:00:42 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 April 2016 12:00:43 UTC