Re: [web-audio-api] (setValueCurveAtTime): AudioParam.setValueCurveAtTime (#131)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335#3) by Marcus Geelnard (Opera) on W3C Bugzilla. Wed, 05 Dec 2012 10:20:25 GMT

(In reply to [comment #3](#issuecomment-24244398))
> (In reply to [comment #2](#issuecomment-24244392))
> > I think the level of detail in the new text is good. One thing that seems to
> > be missing though is what the value is when t < time and t >= time +
> > duration, respectively (most likely values[0] and values[N-1], respectively).
> > 
> > Also, the expression "v(t) = values[N * (t - time) / duration]" is
> > effectively nearest interpolation. Is that intended? Linear interpolation
> > seems more logical.
> 
> The idea is that the number of points in the Float32Array can be large so
> that the curve data is effectively over-sampled and linear interpolation is
> not necessary.
> 
> Fixed:
> https://dvcs.w3.org/hg/audio/rev/a658660f3174

Looks good for t >= time + duration. As for t < time, I guess the curve is not active, so needs not be defined (?).

Why don't we want linear interpolation? Linear interpolation would make the interface much easier to use, and could save a lot of memory. E.g. a plain ramp would occupy 256 KB for 16-bit precision without linear interpolation (and require a fair amount of JavaScript processing to generate the ramp). With linear interpolation the same ramp could be accomplished by a 2-entry Float32Array and minimal JavaScript processing.

I don't think that linear interpolation would cost much more in terms of performance, especially not compared to e.g. the exponential ramp.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/131#issuecomment-24244402