Re: AudioBuffer channel read/write APIs

More talking about completeness than anything else; fully expressive memcpy
effectively has five arguments:

dest, src, dest offset, src offset, count

In a language like C, you encode the offsets into the pointers, that is:

&dest[dest offset], &src[src offset], count

You can't do that trivially in this case, so with the current API it looks
something like

new TypedArrayView(dest.buffer, dest offset, count), src, src offset, count

The lack of symmetry is just weird, especially since given the lack of
symmetry, it becomes unclear which buffer the offset refers to. And the
symmetry is hard to express since in this case one of the buffers is
controlled by the browser, so you can't just make a view out of it.

Mostly I want symmetry here (and in similar operations like memcpy
equivalents) because without it you have to cause a bunch of GC churn by
creating thousands of temporary views, and that's pretty error-prone to
boot.

So essentially I think I'm asking for the Web Audio version of a given API
to be as expressive and symmetric as the C version would be, where
reasonable. This seems like a good opportunity, since it's speccing a new
API that basically just exposes two special variants of memcpy.

(That's also why I'm okay with a version that is just one buffer and an
offset, since everything else can be expressed via a view, if you ignore
the performance consequences)


On Thu, Sep 12, 2013 at 8:56 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Sep 12, 2013 at 5:13 AM, K. Gadd <kg@luminance.org> wrote:
>
>> Arguably no matter the terminology, start/offset are unclear when you
>> have both a source and a destination. IMO either prefix the offset argument
>> (sourceOffset, etc) or allow offsets to be specified for source and
>> destination. Passing both source and destination offsets would make these
>> APIs a lot more useful since they allow you to carve slices out of a much
>> larger buffer, and there's already the length argument. If you just want
>> people to use typed array views for that, probably take out the length
>> argument and just use the length of the source array.
>>
>
> For most uses I could think of, starting at offset 0 of the array was
> fine. How would an offset into the array make this much more useful?
>
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
>