Re: AudioBuffer channel read/write APIs

On Thu, Sep 12, 2013 at 11:49 AM, Jer Noble <jer.noble@apple.com> wrote:

> On Sep 12, 2013, at 11:27 AM, K. Gadd <kg@luminance.org> wrote:
>
> 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)
>
>
>
> FWIW, JSC has been doing a lot of work lately to ensure that the
> performance implications of creating a new TypedArrayView are as minimal as
> possible.
>
> See:
> https://lists.webkit.org/pipermail/webkit-dev/2013-August/025267.html<https://bugs.webkit.org/show_bug.cgi?id=119064>
> https://bugs.webkit.org/show_bug.cgi?id=119064
>
> So in this case, I’d argue that matching the semantics of TypedArrayViews
> (which devs will have to be familiar with just to use this API) is more
> important than baking subtle performance improvements into the spec.  (And
> in my ideal world, we would use TypedArrayView semantics literally. I.e.,
> float32View.set(audioBuffer.channel[0]). But that’s for another day. ;-) )
>

Does that mean you and Kevin are both happy with

partial interface AudioBuffer {
  void copyFromChannel(Float32Array destination, long channelNumber,
unsigned long startInChannel);
  void copyToChannel(Float32Array source, long channelNumber, unsigned long
startInChannel);
}
?

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