Re: "Factory-style" AudioWorker spec proposal

Fine work.  A few off-the-cuff comments.

   - I had been expecting we will need to do a side-by-side non-factory
   audio worker and a factory-based one (i.e. this shouldn't replace the
   AudioWorker I've been spec'ing - it should go alongside.)  This is mostly
   because you cannot replicate the current API's behavior with this factory
   proposal[1] (but also the additional complexity).  This obviously would
   mean the names could not be shared in quite this way.
   - I like the packaging into a single worker script - always did.  I only
   didn't do it that way because of [1].
   - The method name should NOT be "createAudioWorker", because it doesn't
   create and return an object named "AudioWorkerNode" (pattern we've
   established across the API).  I would suggest this should be
   "loadAudioWorker" or, preferably, "loadAudioWorkerFactory".  (particularly
   because the AudioWorker classes can't be shared, due to my first point.
   - I'm not sure why you changed "bits" to be a hard-defined number in the
   bitCrusher example, but it should really be a Param - otherwise it's not a
   particularly real-world.  I think you were just trying to give a
   Transferable example - but I was confused the "var bitsArray =
   e.parameters.bits;" part - is this a leftover?  Regardless, "bits" as a
   Param is a key feature of what a user would want from a bitcrusher.
   - I'd rather not have an addition Transferable opportunity unless
   there's a strong demand; it seems more confusing (we'd have to offer
   guidance on when to use that Transferable vs postMessage vs AudioParam).

-C

[1] You can't replicate this behavior:

var c=new AudioContext();
var comp=c.createDynamicsCompressor();
comp.ratio.value=20;

Note the lack of async opportunity between the first and second line -
i.e., your factory's promise does not have time to complete.

In terms of the goal of Extensible Web Layering, unless we're planning to
refactor the API so the create*() APIs don't exist in their current form,
we need to offer some way to replicate their behavior - so we need a
non-async type.

On Fri, Jan 30, 2015 at 10:49 AM, Joe Berkovitz <joe@noteflight.com> wrote:

> Hi group,
>
> It was great seeing so many of you in person in Paris.
>
> In the spirit of keeping the discussion moving on AudioWorker, I've posted
> a version of the spec that embodies the idea of AudioWorker acting as a
> factory for AudioWorkerNodes.  This allows AudioWorkerNodes to be created
> synchronously (or, at least, as synchronously as native nodes), because the
> script loading phase only occurs once up front, when an AudioWorker is
> created.  The nodes for that worker are created later, after the
> AudioWorker is up and running and its script has run.  The
> AudioWorkerGlobalScope now has an onaudionodecreated handler, called each
> time the factory makes a new node.  That in turn takes care of attaching an
> onaudioprocess handler to the newly created node, as well as doing whatever
> other setup is needed for the node.
>
> You can see my proposal here:
>
>    http://joeberkovitz.github.io/web-audio-api/
>
> I suggest jumping straight to the reworked bitcrusher / VU-meter sample
> code snippets to get the idea and then reading the revised/added interface
> definitions.
>
> Overall it's not far from Jussi's proposal from Sept. 2014 in terms of
> overall concept and naming. There are some differences though.  Also, it's
> forked from Chris Wilson's last published revision and incorporates Chris's
> work on the configurable-input-output changes. Diffs in my version can be
> viewed here:
>
>
> https://github.com/joeberkovitz/web-audio-api/commit/0581c5bddfdacf1e9bef075f91dc76c18e186bda
>
> A few other highlights for possible discussion:
>
> 1. I moved the configuration of node parameters and inputs/outputs into
> the worker script. The argument that these things must be configured in the
> main thread prior to node creation no longer applies (since the entire
> AudioWorker script now runs prior to node creation). From a packaging point
> of view it seemed much nicer to have these shared characteristics of nodes
> defined in the script, not the main thread -- Norbert Schnell raised this
> issue at the WAC conference.  However, this does imply that a single
> AudioWorker can't leverage its script to somehow create nodes with
> different AudioParams or input or output configurations. Others might feel
> differently about this tradeoff.
>
> 2. I allowed the node-creation method on AudioWorker to pass some initial
> Transferable data for the new node, because it felt analogous to the
> constructor args taken by most native nodes.  Maybe this amounts to sugar
> in place of explicitly calling postMessage() on the node immediately after
> its creation, as in Chris's VU meter example. So perhaps this extra
> data-passing opportunity should be taken out -- but I thought the creation
> event for a node was special enough to merit some data being passed in to
> initialize it.
>
> Anyway, hope this is helpful. I'm sure it needs lots more critiquing and
> work.
>
> ...Joe
>