On Mon, Mar 11, 2013 at 8:20 AM, Ehsan Akhgari <ehsan@mozilla.com> wrote: > On Tue, Mar 5, 2013 at 8:45 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > >> On Wed, Mar 6, 2013 at 10:08 AM, Joseph Berkovitz <joe@noteflight.com>wrote: >> >>> I could imagine additional listeners to an AudioProcessEvent for various >>> healthy reasons that are unrelated to filling the buffer. For example. >>> consider generic listeners that can log the periodic activity of any >>> ScriptProcessorNode for debugging/diagnostic purposes, or monitor the >>> overall throughput of the node graph. >>> >> >> FWIW I agree. >> > > I thought some more about this, and I think it makes sense for us to allow > multiple listeners. I'm not sure how filling the buffers should work > though. Allowing modifications only the first time seems error prone, as > there is no good way to make sure that a given listener is always called > first. One perhaps awkward way to address this would be to expose a > readonly boolean attribute such as source with enumerated values "input" > and "script", denoting whether the buffer is coming from an input node or > from the modification performed by another ScriptProcessorNode, and let > scripts which attach multiple event listeners handle this sanely (in some > cases overwriting _might_ be desirable.) > > Thoughts? > Just to add a little more background of how this type of API has been handled in the past, I believe Flash uses a callback. And audio APIs like this in C are callback based. So there is a pretty solid precedent for using callbacks. I'm not sure I've heard any compelling use case for why it has to be an EventListener. It seems to overly complicate the design. Chris > > -- > Ehsan > <http://ehsanakhgari.org/> >
Received on Monday, 11 March 2013 17:12:28 UTC