- From: Joseph Berkovitz <joe@noteflight.com>
- Date: Fri, 8 Oct 2010 07:48:52 -0400
- To: Chris Rogers <crogers@google.com>
- Cc: public-xg-audio@w3.org
> > 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