Re: Draft WebAudio API review text

On Wed, Jul 24, 2013 at 11:05 PM, Janessa Det <jandet@gmail.com> wrote:

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

And a great example. Adding it to the document. Thanks so much!


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

Right. I think I get a bit worried that the JQuery experience might
convince you that you're dealing in terms of "oneShotSound" the whole time,
but I don't think it matters here; and honestly I wish DOM returned
appended nodes in the same way.


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

I think I was going for something more like:

{ node1.in, node1.out } = node1b.someOperation(node2b);

It's not much better and you're right, I don't think it helps. In/out props
would need to be getter/setter pairs and it's not great. What we really
want, I think, are hierarchy properties: "children", "parents", or similar.


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

Right


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