On Fri, Mar 22, 2013 at 5:11 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote: > On Thu, Mar 21, 2013 at 4:15 PM, Joseph Berkovitz <joe@noteflight.com>wrote: > >> >> On Mar 21, 2013, at 12:20 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> >> wrote: >> >> >> On Wed, Mar 20, 2013 at 7:18 PM, Robert O'Callahan <robert@ocallahan.org>wrote: >> >>> Indeed, automatically firing "finished" on a GainNode doesn't make >>> sense, because if even all other JS references have been dropped the event >>> handler could always "resurrect" the node by retrieving the node via >>> event.target and adding a new input to it, and then the node isn't finished. >>> >> >> Good point, my mistake. >> >> >>> A separate "quiescent" event woiuld make some sense, but would have to >>> be carefully defined. >>> >> >> OK, how about we stick to introducing the finished event for >> AudioBufferSourceNode and OscilatorNode for now and eliminate >> playbackState? We can continue discussing the "quiescent" event but I >> don't think that we need to hold the finished event for that, because it >> turns out that it will not be the proper solution for that case. >> >> >> That seems fine -- and I agree that a tool for detecting the >> "finishedness" of an audio buffer or oscillator node is a useful thing. >> > > Great! crogers, do you want me to write up a spec change for this? > Sure sounds good, can we start by just removing the . playbackState and work on the event(s) later? > > -- > Ehsan > <http://ehsanakhgari.org/> >
Received on Saturday, 23 March 2013 00:16:10 UTC