Re: Draft WebAudio API review text

Thank you for the detailed responses -- excited to see how this feedback
document could affect the Web Audio specs (yay Open Standards!).  A quick
clarification re: the .connect chaining response below:

> I feel like I don't have a great proposal here. Returning from connect
seems like it's not exactly what you want; although returning both and
allowing you to use destructuring in ES6 to get closer to the mark might be
better.

The simple solution of returning the destination node (as you propose)
would be a huge first step for cleaning up graph composition code.  As an
example:

Currently connecting up nodes often looks something like this:

oneShotSound.connect(lowpass);
lowpass.connect(panner);
panner.connect(gainNode2);
gainNode2.connect(compressor);
compressor.connect(destination);

With chaining it could look like this -- a one liner -- formatted here for
extra clarity:

oneShotSound
  .connect(lowpass)
  .connect(panner)
  .connect(gainNode2)
  .connect(compressor)
  .connect(destination);

This is a huge win in expressiveness and readability.  Admittedly, things
may still remain a bit complex for more complex audio graphs with many
diverging paths, although being able to at least chain up linear paths
would contribute to simplifying & modularly organizing the definition of
these complex graphs as well.

I have to give it a little more thought, but I am not sure that ES6
destructuring will help in cleaning up the connection of audio graphs.
 First, for code clarity, I think it is important to encourage separation
of the node creation and graph construction imo.  Second, if we are trying
to simplify the definition of branches in a complex audio graph via use of
destructuring, I feel like it would not really address the problem as
neatly as we'd hope.  As an example:

var [branch1, branch2] = [
  node1.connect(node1b),
  node2.connect(node2b)
];

My instinct here would be then wanting to connect the source node to all
these branches I have defined which doesn't work as branch1 and branch2 now
represent the destination nodes node1b and node2b, respectively.  In this
case I would have wanted .connect to return the source then, which is
rather arbitrary and specific to only this use case.  We could use this to
connect to the destination, however, as in:  branch1.connect(dest) and
branch2.connect(dest), but this could be done in each of the branch
definitions anyways.  It does not simplify the code or clarify it imo.

If we return both source and destination nodes to solve this unidirectional
problem, I agree that it could possibly enable a more powerful solution for
being able to connect complex audio graphs in one fell swoop.  However, I
think it would be overly complex and would make the simple chaining
demonstrated above impossible.  It would be more of a confusing lose than a
win.

Please do correct me if I misunderstand what you were thinking in terms of
ES6 destructuring helping in this context.


~Janessa