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? -- Ehsan <http://ehsanakhgari.org/>
Received on Monday, 11 March 2013 15:21:39 UTC