Re: Audio Workers - please review

> 
> Since the recent inclusion of add/removeParameter in the proposal, did anyone (especially Chris :-) consider whether we still truly need postMessage/onmessage support? If we removed it, it would render moot a lot of arguments about what happens when nodes try to talk to each other and might simplify everything a lot. Internode communication seems to me a way to cause a lot of mistaken assumptions re: synchronicity (see above). AudioParams seem cleaner and more in line with what native nodes do.
> 
> I'd argue otherwise. The native nodes have features such as start(), stop(), setting the AudioBuffer of an AudioBufferSourceNode, the custom waveshape of an oscillator, reading data from an analyzer, the type of a filter, etc., none of which are representable reasonably with AudioParams.

I understand your argument. But instead of just accepting that this implies we must support postMessage, I’d like to ask a follow-on question: having allowed exposure of AudioParams in scripted nodes, do we also want to expose functions and attributes (e.g. to let the main thread set custom wave shapes, read analyzer data, etc. etc.)  It seems as though if the goal is to be able to implement native nodes with scripted nodes, this would be necessary, yes?

By the way, I think start/stop are understandable solely in terms of a node’s lifetime and sequencing of its onaudioprocess calls (granted they have nothing to do with AudioParams, but don’t see why they have to do with postMessage support either).

…Joe