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/24244452@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335#10) by redman on W3C Bugzilla. Tue, 11 Dec 2012 16:32:55 GMT

(In reply to [comment #10](#issuecomment-24244444))
> 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?

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

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