Re: Comments on AudioWorklet examples

Hi Hongchan,

Thanks for responding! I will attempt some stunted responses from my phone since I'm traveling today, to keep the discussion going. 

>> Based on our previous discussion, I'd expect that there needs to be a subclass constructor that explicitly copies these values out of the AudioNodeOptions into the new node's AudioParams, like this:
>> 
>> class BitcrusherNode extends AudioWorkletNode {
>>   constructor(ctx, options) {
>>     super(ctx, 'Bitcrusher', options);
>>     if (options.hasOwnProperty('bitDepth') {
>>       this.bitDepth.value = options.bitDepth;
>>     }
>>     // ...initialize other params, initial state up front, possibly utilizing postMessage()...
>> }
> 
> Just to confirm: so this is a node definition, not the processor? Initializing these values from the main thread is a definitely better idea, but the pattern here is quite involved and verbose. I think we can start from this idea and try to simplify the syntax to find a sweet spot. I really need to think about having two definitions for both threads. Very explicit, but that also makes us diverge from Worklet infrastructure which I am a bit afraid of.

Sorry, I don't see where this diverges from Worklets -- what am I missing? 

The reason I made this a subclass is because otherwise I did not see how to make use of the custom AudioNodeOptions entries that your example employed  to initialize the bitcrusher AudioParams. The options are constructor args, so unless there is some behavior in AudioWorkletNode that automagically initializes AudioParams with matching names, I don't see how else it can happen. 

If you do envision this init behavior then please make it explicit. Would it apply only to AudioParams? (I assume so because nothing else about a Processor can be declared)

Of course one could leave the Params out of the ctor options argument and just initialize them after creating the AudioWorkletNode.
> 
> 
>> 2. When are the params for a node determined, and when can they change? We've changed up the lifecycle quite a bit now, so I'm not sure what the answer is. I recall that we went to some trouble before to ensure that the set of params was known at the actual time that an AudioWorkerNode was instantiated, just like they would be for a native node.
> 
> We can introduce event like `created` for the instance-specific initialization. I find this pattern is very useful when using Polymer.
> 
> class BitCrusherProcessor extends AudioWorkletProcessor {
>   constructor () { /* this is called when the instance is created. */ }
>   created () { /* this is called the initialization for both threads is done. */ }
>   process () {...}
> }
> 

Create() Seems good but optional.

I just wanted to make sure that our mechanism allows a new AudioWN to exhibit the parameters that were defined, from the moment of its instantiation. 

> 
>> The only opportunity we have to discover parameter descriptors is before the success of the promise from the script import for a node type.
>>   So *maybe* it works like this: after the script is imported for an AudioWorkletProcessor, the Processor gets instantiated once prior to the success of the Promise and its paramDescriptors getter is examined; the result determines the set of parameters exposed by subsequent nodes of that type. The Processor instance is then thrown away; its only purpose was to figure out what params exist for this node type.
> 
> Can you elaborate on this a bit more? I am not sure if I am following you.

Along the lines of my previous response, I was asking myself how the API can know what parameters exist for a Node whose Processor doesn't exist yet. Yet it is the Processor that exposes the param descriptors. 

The only way I see for this to happen is for a Processor to be created as part it's registration, solely for the purpose of interrogating its param descriptors. 
>  
> 
>> This would make it hard to add/remove parameters on the fly. But I don't know that this is important.
> 
> I am opposing to the idea of adding/removing parameters on the fly. The current AudioNodes do not support this, so I guess this is where we draw the line for V1.

+1 on that. 

...Joe