[Bug 17335] (setValueCurveAtTime): AudioParam.setValueCurveAtTime

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335

--- Comment #11 from redman <bugzilla@redman.demon.nl> ---
(In reply to comment #10)
> 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.

Well, the problem is kindof that there will be very different requirements
depending on what the audioParam is controling.
Sometimes nearest neighbour is what you want, sometimes it's linear
interpolation and sometimes you just need a properly antialiassed signal or
just a smooth signal.
If i control the the pitch of an oscillator with note data then i usually don't
care about aliasing. In this case i want no filtering  at all.
But if i control the volume of a gain node with a function and it alows me to
use a variable rate sample then i would expect that sample to be properly aa'ed
at any rate.

I'm not sure a filter would be that much more complicated. There is already a
filter active on the setValue method of AudioParams.
The curves capability allows people to use vastly unsuitable material (complex
sound played above samplerate) as input to the AudioParam. 
Using AudioBufferSourceNode may be problematic with scheduling and there is
already a problem with the SetValue as it always applies a heavy filter to
changing values in the current implementations. I believe that is the reason
the Curve was invented in the first place.
So why not just make it right instead of expecting the user to know/find out in
what ways it is broken?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 11 December 2012 16:33:06 UTC