Re: The issue of ScriptProcessorNode not being an EventTarget

Hi Chris,

While I agree that it's essential to process the output only one time per callback -- that's a given -- I don't immediately see that this means that multiple listeners are a broken idea. I would not design the API to rule them out, I would instead emphasize that the buffer can only be filled once.

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.

By analogy, one doesn't want to handle the gesture expressed by a MouseEvent more than once -- but programmers find many good reasons to field the same event in multiple listeners, only one of which actually handles the gesture.

…Joe


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

> 
> 
> On Mon, Mar 4, 2013 at 4:10 PM, Joe Berkovitz <joe@noteflight.com> wrote:
> FYI I had hoped to discuss this on last Thursdays call.
> 
> I think it's an important point to resolve as soon as we can. But I sure don't want to slow down an implementation by waiting for the resolution.
> 
> Chris, can you remind us why this case should not follow the general pattern of event target/handler pairs? I'm hard pressed to think of other cases where one would only have an "on" callback with no associated dispatchable event, and it seems plausible (though not obvious) that one could have multiple listeners in this case.
> 
> I'm sorry, my mistake.  I just realized we *are* talking about ScriptProcessorNode, when I thought we were talking about OfflineAudioContext.  I think it's very bad to have multiple listeners for ScriptProcessorNode because it's important to process the output only one time per "callback".  Otherwise, a clean continuous output stream would not be generated.  Thus it really needs to be a callback and not an EventListener.  Let's not drive the decision based on the current name of the attribute.
> 
> As for the naming we can either:
> 
> 1.  live with the fact that "onaudioprocess" *seems" to imply an EventListener, although it really is a callback.  I'm not sure if there's any explicit rule that a callback can not in any circumstances have this naming convention.  If there is such a rule, then it seems a bit silly.
> 
> 2. Change the name of the callback to something different and break all current pages using this node.  My opinion is that this would be a very serious breaking change.
> 
> I prefer option (1)
> 
> Chris
>  
> 
> .       .    .  . ...Joe
> 
> Joe Berkovitz
> President
> Noteflight LLC
> +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere."
> 
> On Mar 4, 2013, at 6:38 PM, Chris Rogers <crogers@google.com> wrote:
> 
>> 
>> 
>> On Mon, Mar 4, 2013 at 3:01 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote:
>> This issue is still pending but we need to move forward with _a_ decision on the Gecko side of things, so I'm just going to assume that the spec is going to get updated to make AudioNode an EventTarget and make onaudioprocess an EventHandler.
>> 
>> Cheers,
>> 
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>> 
>> Hi Ehsan, I had hoped we could make it be a simple Callback, but this doesn't seem to really affect what the JS code using the API would look like, so I'm not that hung up on it.  I certainly don't want to block any progress you're making with the OfflineAudioContext.  
>> 
>> Chris
>>  
>> 
>> 
>> On Thu, Jan 24, 2013 at 6:49 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote:
>> Olli filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20764 a few minutes ago.  This is a bug that I hit when I was trying to implement ScriptProcessorNode.  Basically, as things stand, ScriptProcessorNode is not implementable in Gecko without the sort of hacks which WebKit seems to be going through, and we would really like to avoid that.
>> 
>> It look like the best way to deal with this is to make AudioNode inherit from EventTarget, and make onaudioprocess an EventHandler.
>> 
>> This is currently very high priority for the Gecko implementation since we are on the verge of landing initial audio playback support, and we need to implement ScriptProcessorNode as a way to test the ongoing work on the audio playback support.
>> 
>> Chris, I'd appreciate if you could please take a look into this and address this issue at the spec level.  It's sort of a big change, so I don't want to just assume things and proceed on the implementation side.
>> 
>> Thanks!
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>> 
>> 
> 

... .  .    .       Joe

Joe Berkovitz
President

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