Re: "Factory-style" AudioWorker spec proposal

Concerning naming issue, its seems that "createAudioWorkerFactory" would be be even better than "loadAudioWorkerFactory", since "loading" is not always what is going to happen. An application may perfectly want to dynamically creates the code to be used by the factory. An embedded Domain Specific language like Faust is a perfect example of this need, and actually already does that: take a DSP source code, compiles it in asm.js code, build a factory, then creates DSP instances from the factory.

Stéphane Letz

Le 30 janv. 2015 à 01:47, Chris Wilson <cwilso@google.com> a écrit :

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

Received on Friday, 30 January 2015 03:39:02 UTC