Re: Proposal: JavaScriptCueNode

>
> Hi Joe, this sounds like a useful idea.  But, I think that I  
> wouldn't implement it as an AudioNode since it's not processing  
> audio in any way, but instead as a method on AudioContext, something  
> like:
>
> context.scheduleTimer(time, callbackFunction);
>
> The "time" parameter would be on the same timescale as the  
> "currentTime" attribute of the context.  Special care would need to  
> be taken to ensure that excessively large numbers of event listeners  
> don't get fired.  Some kind of throttling mechanism would need to be  
> implemented.  This all has to be balanced with the throttling  
> mechanism for others timer such as setTimeout().


I was thinking it should be an AudioNode because this permits self- 
contained subgraphs to encapsulate their own event generation code as  
internal nodes. This is analogous to the other issue I've raised about  
encapsulation of scheduling concerns.  In any case it's not an  
absolute requirement and a method on the context works fine.

I don't see that huge numbers of listeners should be needed, I see  
this as a small point feature that makes common periodic scheduling  
tasks much more straightforward.

  .  .    .       Joe

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

Received on Friday, 8 October 2010 11:49:33 UTC