I'm OK with this solution although I fail to really the see the use case of post-creation modifying AudioBuffers. I'd also suggest that instead of a slice() there would be a function to copy the data to an existing array, not sure what would be the logical name of that method (it should actually be an overload of Float32Array#set() since it's inversion of control, and it's hard to name out-of-place methods, but I doubt we want to touch Float32Array), but the signature would be something like: void copyTo (Float32Array target, optional unsigned long offset); So that would change forced memset + malloc to just memset and leave the malloc up to the developer. Cheers, Jussi On Fri, Jul 19, 2013 at 5:11 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote: > I also think the combination is a good idea. > > -- > Ehsan > <http://ehsanakhgari.org/> > > > On Thu, Jul 18, 2013 at 8:09 PM, Jer Noble <jer.noble@apple.com> wrote: > >> >> On Jul 18, 2013, at 4:54 PM, Robert O'Callahan <robert@ocallahan.org> >> wrote: >> >> Both of those proposals look pretty good to me. >> >> I would also support a combination of the proposals that lets >> AudioBuffers be mutable, but adds "Constructor(Float32Array[] arrays, float >> sampleRate)" and makes outputBuffer non-readonly. >> >> >> I thought that might be popular. :) >> >> I’m updating the proposal here: <https://gist.github.com/jernoble/6034137>, >> and I’ll incorporate suggestions (including this one). >> >> -Jer >> >> >
Received on Friday, 19 July 2013 07:34:20 UTC