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 18:26:55 +0000
To: public-audio@w3.org
Message-ID: <bug-17335-5429-giqyCEY1TV@http.www.w3.org/Bugs/Public/>

--- 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

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

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

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