[Bug 17335] (setValueCurveAtTime): AudioParam.setValueCurveAtTime

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

--- Comment #12 from Chris Rogers <crogers@google.com> ---
Here's my take:

AudioParam already has several ways of being controlled:

1) linear and exponential ramps: these are *very* well established ways of
controlling parameters going back decades in computer music systems and synth
design.  Furthermore, these can be a-rate, so much smoother than systems which
work exclusively using k-rate.

2) arbitrary curves: These are mostly useful as slowly varying curves, but can
be oversampled to a very high degree (2x, 4x, 8x) by providing a Float32Array
which is far longer than the duration of the curve.  I don't think we should be
worried about memory performance here since these will still generally be much
smaller than the audio assets themselves.  This oversampling can help to a
great degree to band-limit the signal.

3) control via audio-rate signals: These signals can be band-limited to the
extent that source node, and the processing nodes use band-limited approaches.

Especially with (3) we have a pretty rich possibility of controlling the
parameters, including ways which are concerned about band-limited signals.

This does bring up other areas of the API which need to be concerned with
aliasing:

AudioBufferSourceNode: currently its interpolation method is unspecified. 
WebKit uses linear interpolation, but cubic, and higher order methods could be
specified using an attribute.

OscillatorNode: once again the quality could be controlled via attribute. 
WebKit currently implements a fairly high-quality interpolation here

WaveShaperNode: there are two aspects of interest here:
1) How is the .curve attribute sampled?  Currently the spec defines this as
"drop sample" interpolation and not even linear, but we should consider the
option of linear.  I'm concerned about this one because I notice people are
using the WaveShaperNode for distortion with relatively small curves (such as
8192 in tuna.js) which will end up not only shaping the signal, but adding a
bit-crushing/bit-decimation effect, which may or may not be the effect wanted)

2) Is the wave-shaping curve applied at the AudioContext sample-rate, or is the
signal first up-sampled to a higher sample-rate to avoid aliasing??  The option
to have band-limited wave-shaping will become more and more important with the
advent of applications like guitar amp simulations.  Aliasing can seriously
affect the quality of the distortion sound.  We know people are interested in
these kind of applications, since they're already showing up:
(Stuart Memo's work, tuna.js, and
http://dashersw.github.com/pedalboard.js/demo/)

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

Received on Tuesday, 11 December 2012 18:27:01 UTC