Re: The issue of ScriptProcessorNode not being an EventTarget

Hi Chris,

1. In point of fact Flash does not use a callback.  Flash dispatches a regular event when samples are to be provided from ActionScript, and the event carries a read-only accessor for the buffer into which the samples are to be placed. The event could in theory have multiple listeners.  See:

  http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/media/Sound.html#event:sampleData

2. I'll mention again (since you didn't respond to this directly) that "secondary" event listeners are often usefully employed to register the fact that an event occurred, even if they do not directly handle the event. Often such uses are motivated by diagnostics or analysis. I believe that Robert was responding positively to this point.

3. In contrast to Ehsan's suggestion, I don't wish to see the design overcomplicated or embroidered in order to permit multiple listeners to supply data. I do not see the need to split the sample-provider responsibility between different event listeners, this seems like a very unlikely use case to me. But let's not say "no" to EventTargets for this reason.

…Joe

On Mar 11, 2013, at 1:11 PM, Chris Rogers <crogers@google.com> wrote:

> 
> 
> 
> 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/>
> 

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"