Re: New proposal for fixing race conditions

I support this solution too. It's very similar to a suggestion I had in
mind.

I agree with Jussi that it would be good to be able to read into an
existing array, since that would lessen the heap allocation activity. Not
sure if it should replace the slice() method, we could just as well have
both IMO.

Also, I think it would be useful to have a more specific version of the set
operation, in order to be able to update only a sub-part of the
AudioBufferChannel from a sub-part of the source array (use case: editing &
updating small parts of a large AudioBufferChannel). It would have to take
two more arguments, e.g:

void set(Float32Array array, optional unsigned long dstOffset,
optional unsigned long srcOffset, optional unsigned long srcLength);


Regards,

  Marcus


On Fri, Jul 19, 2013 at 9:33 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

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