Re: asynchronous vs synchronous instantiation of AudioWorkerNodes

On Nov 6, 2014, at 4:50 PM, Chris Wilson <cwilso@google.com> wrote:
> Conclusion:
> Keeping in mind your custom code can encapsulate the worker scripts, I think it's better if we just presume that "component" scripts will be main-thread scripts that package up (as blob, e.g.) the worker script, and then encapsulate a factory method or object constructor.
> 
> E.g.:
> 
> <script src="worker-based-gain.js"></js>  <!-- packages up the worker, and exposes MyGainNode constructor -->
> <script>
>     var gain = new MyGainNode( audioContext );
>     gain.gain.value = 0.5;
> </script>
> 

OK, so IIRC your suggestion corresponds to this proposal in my list, yes?

> - Don’t return a Promise. Continue to have createAudioWorker() return an AudioWorkerNode, synchronously. This node presumably isn’t ready to function yet, but it could be inserted into the graph. Script loading would happen later, after which the node would initialize (possibly posting a message back to the main thread to signal this). 

As a best practice you are suggesting that a library that “fronts” for custom nodes can do some local caching of worker scripts as Blobs, etc. which will minimize the delay between the node’s instantiation and its subsequent loading of the script and processing audio. It seems to me that this still means that JS loading/parsing (albeit from some kind of local storage) is taking place on a per-node basis.

That may be workable, but could you please explain why the two proposals in which a node factory is created from a preloaded script don’t work for you? It would seem desirable to separate worker-script loading from worker node instantiation if at all possible, much as the API separates buffer loading from buffer node creation.

…Joe