Re: The issue of ScriptProcessorNode not being an EventTarget

On Tue, Mar 12, 2013 at 4:46 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

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


>From an implementation perspective (Chrome) it is preferable to extend
EventTarget than to mix it in.

If the consensus is that ScriptProcessorNode should be an EventTarget, does
it make sense for AudioNode to be an EventTarget? This would both reflect
both the consensus and simplify implementations.

I note that the channel count is a property of AudioNode, not
ScriptProcessorNode. So for Jussi's use case of firing an event when
channel counts change, it may make sense to fire that event on different
types of AudioNodes, not just ScriptProcessorNodes.

I propose this:

interface AudioNode : EventTarget {
  ...
}

interface ScriptProcessorNode : AudioNode {
  ...
}

Regards,

Dominic


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