Next steps on AudioWorklets

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