W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 17335] (setValueCurveAtTime): AudioParam.setValueCurveAtTime

From: <bugzilla@jessica.w3.org>
Date: Tue, 11 Dec 2012 09:08:04 +0000
To: public-audio@w3.org
Message-ID: <bug-17335-5429-BAout6myBg@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335

--- Comment #10 from Marcus Geelnard (Opera) <mage@opera.com> ---
(In reply to comment #9)
> 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 11 December 2012 09:08:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:04 UTC