Re: The issue of ScriptProcessorNode not being an EventTarget

On Mon, Mar 11, 2013 at 12:17 PM, Joseph Berkovitz <joe@noteflight.com>wrote:

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

As long as the design doesn't get overly complicated (more complicated than
it is now), EventListener seems ok.


>
> …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"
>
>