Re: Next steps on AudioWorklets

Hi Joe,

Glad we reached the point where we can draw the line and move forward.

> The AWN constructor synchronously instantiates its corresponding AWP
within the AWGS.

Yes, this is the most important detail we clarified today.

> The type string passed to the AWN constructor is used to locate the
previously registered AWP class.
> The AWN constructor must throw an exception if no registered AWP class
exists for the given type string.

Agreed.

> parameterDescriptors will become a static getter (or attribute?) in the
AWP class.

Correct. ES6 static getter. So the descriptor is available even before the
instantiation.

> Within the AWN constructor, any entry in the "options" argument whose key
matches a AudioParam declared by the AWP will automatically initialize that
AudioParam's value for this AWN. Thus, developers do not need to write code
to initialize AudioParams.

A bit of magical part that we need to embrace. Yes.

> The AWN constructor's "options" argument will be propagated via
structured cloning to a new AWP constructor argument also called
"options". This allows the state of an AWP (other than AudioParams which
are handled above) to be initialized synchronously and completely, as part
of the construction of its corresponding AWN. The use of postMessage() is
now only needed to communicate data following AWN/AWP initialization, which
simplifies coding quite a bit.

Yes.

> AWNs may be subclassed to "shrink wrap" a custom node. This is not
required, and it does not add any new features to the API: any AudioNode
can already be subclassed as per the new spec. The advantages are that this
subclass can hide the type string, and it can also hide
postMessage/onmessage communication for AWP state changes and updates
behind getters, setters and regular methods.

This is a great improvement that comes with AudioWorkletNode + subclassing!

-Hongchan

On Thu, Jun 2, 2016 at 12:53 PM Joe Berkovitz <joe@noteflight.com> wrote:

> Hi Group,
>
> Here's my quick list of the AudioWorklet changes I understand as coming
> out of today's call -- sort of a verbose version of the minutes, as I
> remember them:
>
> - The AWN constructor synchronously instantiates its corresponding AWP
> within the AWGS. The type string passed to the AWN constructor is used to
> locate the previously registered AWP class.
>
> - The AWN constructor must throw an exception if no registered AWP class
> exists for the given type string.
>
> - parameterDescriptors will become a static getter (or attribute?) in the
> AWP class (this makes them available up front at AWP class registration
> time and disallows dynamic changes in AudioParams).
>
> - Within the AWN constructor, any entry in the "options" argument whose
> key matches a AudioParam declared by the AWP will automatically initialize
> that AudioParam's value for this AWN. Thus, developers do not need to write
> code to initialize AudioParams.
>
> - The AWN constructor's "options" argument will be propagated via
> structured cloning to a new AWP constructor argument also called "options".
> This allows the state of an AWP (other than AudioParams which are handled
> above) to be initialized synchronously and completely, as part of the
> construction of its corresponding AWN. The use of postMessage() is now only
> needed to communicate data following AWN/AWP initialization, which
> simplifies coding quite a bit.
>
> - AWNs may be subclassed to "shrink wrap" a custom node. This is not
> required, and it does not add any new features to the API: any AudioNode
> can already be subclassed as per the new spec. The advantages are that this
> subclass can hide the type string, and it can also hide
> postMessage/onmessage communication for AWP state changes and updates
> behind getters, setters and regular methods.
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> President
> Noteflight LLC
>
> +1 978 314 6271
>
> 49R Day Street
> Somerville MA 02144
> USA
>
> "Bring music to life"
> www.noteflight.com
>