Re: The issue of ScriptProcessorNode not being an EventTarget

Oh, another thing is that making ScriptProcessorNode an EventTarget makes
it a lot easier for us to extend it with possible future events, such as
'onchannelcountchange', etc.

Cheers,
Jussi

On Mon, Mar 11, 2013 at 9:44 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> I think making the ScriptProcessorNode an EventTarget is a good idea. Web
> Audio API is already full of novelties, I don't think we should go
> inventing our own type of event listeners on top of all that. I'm pretty
> sure there are plenty of people who expect that if there's an `onsomething`
> then you can use `addEventListener` for it. On the other hand if we go with
> something like onAudioProcess it's even more "wat".
>
> On the notion of making the buffer readonly after the first event handler:
> seems to me like pointless complication for no gain; Secondary event
> handlers can either analyze the data *or* modify it, for example applying
> some effects.
>
> Cheers,
> Jussi
>
>
> On Mon, Mar 11, 2013 at 9: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.
>>
>> …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"
>>
>>
>