Re: AudioWorklet examples

Hello Joe - thanks for the clarification! I am actively working on it and
hopefully get this done soon.

Perhaps it'd better for us to discuss technical issues on the tracker for
the reference, but here's my follow-up:

> 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.

I am not sure if I am understanding right. What I wanted to point out is to
have a property rather than a getter. However, I think the getter is
actually better, since it prevents the descriptors from changing after the
definition.

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

Sharing data between nodes should be done via postMessage/onmessage. Using
a global variable inside of AudioWorkletGlobalScope is sort of a hack. Also
the timing and the order of data access cannot be defined. (thus the result
will be flaky.)

On Fri, Apr 29, 2016 at 5:00 AM Joe Berkovitz <joe@noteflight.com> wrote:

> 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.
>
> ...Joe
>