Fwd: Serialization/introspection of the node graph

What you say may well be so, but I don't necessarily see how that must be
the case, nor how this idea conflicts with the current garbage collection
model.  Certainly, at the time of serializing a subset of nodes, those
nodes either exist or they don't.  Serializing a portion of the node graph
would necessarily be an atomic operation, and you'd have the JS references
to the objects immediately after they were instanced.

If you want a use case, imagine that we've created a really nice vocal
warming effect with a biquad filter, a de-esser and a compander.  We'd then
like to instance this group n times for use on n channels of audio input.
 For this use, we'd like to represent this subgraph as a single large node,
with exactly one input and one output.  Instancing this subgraph n times
helps us solve our problem.

Another extremely common use case: I want a generic audio effect that
incorporates a bounded, random amount of pitch shift and gain, and I want
to apply it to all the footsteps in my game.  An audio designer would
prefer to have all these effects wrapped into a new effect node which can
be easily instanced, as opposed to instancing all these objects
individually in JavaScript.

This instancing might be done in several ways.  Serialization and
deserialization of an existing subgraph is one way to accomplish this.
 There are other ways to accomplish as well, including serialization of the
Web Audio API itself, so that command sequences could be recorded and
replayed.

jwb


On Sat, May 25, 2013 at 12:21 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sat, May 25, 2013 at 1:48 AM, John Byrd <jbyrd@giganticsoftware.com>wrote:
>
>> In short, while the Web Audio API is great for JavaScript programmers,
>> and the functionality I describe can certainly be implemented in JavaScript
>> above the API layer, -all- audio applications will eventually need or
>> desire the functionality I describe or some part of it, and therefore it
>> might be of use to consider standardizing the process for serializing
>> portions of and/or all the current Web Audio state.
>>
>
> Adding methods to AudioNodes to let you traverse the node graph would
> actually prevent us from doing some very important optimizations (i.e.,
> silently deleting nodes that have completely finished playing and are not
> otherwise referenced). So we shouldn't do that.
>
> A Web app can explicitly keep track of the structure of the graph it has
> constructed (although they're likely to defeat the above optimizations by
> doing so). If you want to write a spec for how that is done, and/or write a
> spec for (de)serializing a node graph --- and implement a library that
> follows that spec --- go ahead. That can be completely separate from the
> Web Audio API spec itself, as long as it doesn't require changes to
> browsers.
>
> Rob
> --
> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq
> qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq
> qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q
> qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
>



-- 
---

John Byrd
Gigantic Software
2102 Business Center Drive
Suite 210-D
Irvine, CA   92612-1001
http://www.giganticsoftware.com
T: (949) 892-3526 F: (206) 309-0850



-- 
---

John Byrd
Gigantic Software
2102 Business Center Drive
Suite 210-D
Irvine, CA   92612-1001
http://www.giganticsoftware.com
T: (949) 892-3526 F: (206) 309-0850