Re: The issue of ScriptProcessorNode not being an EventTarget

On Tue, Mar 12, 2013 at 5:39 AM, Dominic Cooney <dominicc@chromium.org>wrote:

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

Sounds good to me.

Cheers,
Jussi


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