Re: Some additional requirements for the ScriptProcessorNode ..

Hello,

     As a sound modeler who makes heavy use of ScriptProcessorNodes, I 
have to say that this would make my life so much easier.  Bringing 
ScriptProcessorNodes in to the family of other Audio Nodes with a 
consistent behavior and API would enable many more developers to push 
this amazing emerging audio engine in to new creative territory.
     Kumar - your post with details and elegant code was (as always) 
enlightening.
     I second the motions!

Thanks,
                  - lonce


On 1/30/2013 1:51 PM, Srikumar Karaikudi Subramanian wrote:
> Hi all,
>
> When designing abstractions for building sharable audio
> components, the ScriptProcessorNode's peculiarities make it
> rather problematic to deal with compared to the native nodes.
> In particular, the absence of built-in scheduling and dynamic
> lifetime management capabilities necessitates special treatment
> for these nodes. The following suggestions help remove these
> problems.
>
> 1. Permit creation of script nodes without inputs.
>     This better models source nodes. Passing 0 for
>     "number of input channels" may be enough at the API level.
>
> 2. Add start(t) and stop(t) methods to permit script nodes
>     to be used as signal sources, with such nodes not taking
>     up any system resources during their inactive periods.
>     It would be possible to automatically add start/stop methods
>     if the node is recognized as a source node at creation time.
>
> 3. Add dynamic lifetime support similar to native nodes,
>     whereby unreferenced “signal processor” script nodes driven
>     by source nodes are automatically released once the source
>     node finishes, even if the source node is itself a script node.
>     To achieve this, the time at which the inputs cease must
>     be available as part of the event structure passed to the
>     onaudioprocess callback, so that the callback can begin
>     any tail phase that it needs to complete before it commits
>     suicide.
>
> 4. Specify a convention and/or API to support tail times beyond
>     the time indicated in a stop(t) call or after its inputs have
>     been end-of-lifed.
> 	
> I wrote a (rather lengthy) post that works through a simple
> use case (an oscillator driving a gain node to make a "chime")
> to show the need for the above additions.[1] The post
> is somewhat code-heavy, but that's part of the point. Doing what
> it set out to do shouldn't need much code! The functionality
> for the above features is captured in the function named
> "scriptWithStartStopTime" towards the end of the post [2].
>
> Happy to be educated about anything that I may have
> misunderstood here.
>
> Regards,
> -Kumar
>
> [1] http://sriku.org/blog/2013/01/30/taming-the-scriptprocessornode/
> [2] http://sriku.org/blog/2013/01/30/taming-the-scriptprocessornode/#final-scriptWithStartStopTime
>

Received on Wednesday, 30 January 2013 15:09:44 UTC