W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

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

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:54 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/131/24244444@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335#9) by Marcus Geelnard (Opera) on W3C Bugzilla. Tue, 11 Dec 2012 09:08:04 GMT

(In reply to [comment #9](#issuecomment-24244438))
> Certainly not! :)
> No, just refering to curves.
> As for the other other parameters, it would be handy to have a 'better than
> linear/ramp' interpolator that can be switched on or off.
> But (AA)filtering would only be necessary when oversampling, as can be the
> case with curves.

Well, I'm pretty sure that a mathematical exponential ramp exhibits an infinite frequency spectrum (i.e. requires an infinite number of Fourier terms to reconstruct properly), and that just sampling it without any filtering will indeed result in aliasing. This is also true for a linear ramp, or even a simple setValueAtTime.

That's analogous to what would happen if you implemented the Oscillator node with just trivial mathematical functions (such as using the modulo operator to implement a saw wave).

I guess that my point is: Do we really have to care about aliasing filters for AudioParams at all? It would make things much more complicated. If you really want to do things like Nyquist-correct sampling of a custom curve, you can use a AudioBufferSourceNode as the input to an AudioParam instead.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:36:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC