Absolutely. I'll try to change the spec in time for the f2f next week! Thanks! -- Ehsan <http://ehsanakhgari.org/> On Fri, Mar 22, 2013 at 8:15 PM, Chris Rogers <crogers@google.com> wrote: > > > > 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:17:40 UTC