AudioNode API Review Part 2 (Response to spec)

Hi all,

This is the 2nd installment of my review of the Web API.  This is not  
a comparison, but more of a response to the API on its own merits.

------------------------

AudioNode

Will there be an API convention whereby input/output indices are  
symbolic constants in the corresponding Node interface?

AudioParam

This appears to be at least partly metadata.  So perhaps there can be  
some attribute in AudioNode (audioParams?) that returns an array of  
the AudioParams associated with the concrete Node instance, to make  
the class's metadata discoverable in a regular way.

DelayNode

It feels important to understand the philosophy and the resource  
consumption of a DelayNode.  Does it have the "auto-magical" effect of  
causing an isolated subgraph upstream from it to be scheduled to  
render itself later than normal (which would use minimal memory), or  
does it actually buffer the delayed samples from its input  
regardless?  If the former, then that's important to know, and it  
makes DelayNode a valuable building block in audio scheduling (a la  
the Performance object I described in previous posts).  If the latter,  
then it feels important to communicate its likely resource usage in  
the spec.

AudioBufferSourceNode

Needs an integer r/w attribute loopStart at a minimum.  loopEnd would  
be useful too, since many wavetable samples are supplied by vendors  
with both a start and end frame (even though the portion after the end  
frame is useless -- go figure!).

What happens when noteOn() is invoked prior to the node's connection  
to a destination?  If the connection occurs before the note plays, is  
the play request honored on a delayed basis?  If the connection  
follows playback, does the note start playing in the middle?

I don't like the names noteOn()/noteOff(), they feel a little too  
musical (this coming from a music guy, but, hey...)  I prefer  
startAt() and stopAt(), which also transfer to the "automation/ 
modulation" realm without requiring a name change.

What happens when playbackRate is dynamically changed?  If a note is  
playing, Is this done in a way that preserves the current sample frame  
counter to avoid generating artifacts?

noteGrainOn() seems too clever.  What if one doesn't want a "grain  
window" with a smooth fadeout?  I would prefer a clear way to play a  
slice of some sample with no accompanying smarts; windowing can be  
accomplished by a downstream node.  I think the "grain" idea is  
overspecification, I want noteSegmentOn() or something like that.

I think the envelope aspects of note playback need to be cleared up.   
Is there going to be some additional attribute representing an  
envelope, or will envelopes be supplied by downstream nodes?

Dynamic Lifetime

This is a little unclear on the all-important question of when nodes  
are added to the graph -- it speaks more in terms of tear-down.

The Digital Sheet Music use case (which perhaps is already addressed  
by the current implementation) encourages the creation of a very large  
number (often in the tens of thousands) of "note" style nodes which  
represent the events in a score, and which are all connected to a  
single destination.  Ideally this is not a problem, since at any given  
time only a small number (often 10 or less) are actually being  
played.  I can imagine the implementation of Dynamic Lifetime taking  
care of this just fine by "protecting" the destination node from  
seeing notes that are not currently active.

If this is true, then it should be made clear. This aspect of the Web  
API is one of its most important features, and programmers will really  
need to understand its capabilities in order to take advantage of it  
properly.

If this is not true, then that also needs clarification, since  
developers will have to play annoying tricks and games to avoid  
overscheduling too many nodes and overwhelming the engine.  Hope this  
isn't the case.

----------------------

That's all for now!  One more email coming, with a simple feature  
proposal.

... .  .    .       Joe

Joe Berkovitz
President
Noteflight LLC
160 Sidney St
Cambridge, MA 02139
phone: +1 978 314 6271
http://www.noteflight.com
http://joeberkovitz.com