From: Chris Rogers <crogers@google.com>

Date: Sun, 11 Dec 2011 17:58:49 -0800

Message-ID: <CA+EzO0=qugC898Dx5Fu1UPCfexNDE661GaUO_0=rfcQBzQ+umw@mail.gmail.com>

To: Raymond Toy <rtoy@google.com>

Cc: Alistair MacDonald <al@signedon.com>, public-audio@w3.org

Date: Sun, 11 Dec 2011 17:58:49 -0800

Message-ID: <CA+EzO0=qugC898Dx5Fu1UPCfexNDE661GaUO_0=rfcQBzQ+umw@mail.gmail.com>

To: Raymond Toy <rtoy@google.com>

Cc: Alistair MacDonald <al@signedon.com>, public-audio@w3.org

Those who don't care about tweaky math details can skip this message :) On Mon, Nov 28, 2011 at 1:47 PM, Raymond Toy <rtoy@google.com> wrote: > > > On Mon, Nov 28, 2011 at 11:39 AM, Alistair MacDonald <al@signedon.com>wrote: > >> Hi Group, >> >> While working with the Web Audio API at TPAC I was taking some notes. I >> sent these to Chris Rogers and we started discussing this a few weeks back. >> >> Some of the technical discussion may be very useful / interesting to >> people experimenting with the API, so I'm going to forward the thread to >> public-audio here. >> >> At the bottom of the email I have attached the original notes I sent to >> Chris. >> >> Comments/discussion always welcome, >> >>> >>> P O S S I B L E - B U G S >>> =========================== >>> >>> >>> >>> AudioParam ...RampToValueAtTime( 0, 0 ) >>> --------------------------------------- >>> >>> Exponential ramps do not seem to work properly when starting using >>> "zero" values. >>> I would expect to hear the sound ramping in from 0 or out to 0, instead >>> the >>> transition appears to be immediate when it reaches the given time. Much >>> like the >>> behavior of the setValueAtTime() method. >>> >> >> This is a consequence of the math behind exponential curves. You can >> always have an exponentially increasing curve from >> value1 -> value2 >> >> > It's not clear from the webaudio docs what an exponential ramp should do, > but we could define the ramp to be > > value1 + (value2-value1)*(1-exp(-t/C)) > > This will be an exponential ramp starting at value1 and asymptotically > approaching value2. > > Two major differences: > > > - 0 is valid starting point. > - We never actually reach value2, but just get closer and closer. > > Ray > Hi Ray, Sorry I should add more detail in the Web Audio spec about this. In the meantime, here are some comments: this asymptotic approach that you're describing is exactly what the AudioParam. setTargetValueAtTime() does: // Exponentially approach the target value with a rate having the given time constant. void setTargetValueAtTime(in float targetValue, in float time, in float timeConstant); But this is different than AudioParam. exponentialRampToValueAtTime() (exponential ramp): void exponentialRampToValueAtTime(in float value, in float time); For value2 > value1: 1. exponential ramp: value increases exponentially (slowly at first, then faster and faster - as time increases) 2. exponential approach: (setTargetValueAtTime) value increases quickly at first, but then value changes slower and slower as value asymptoticly approaches target value) Both (1) and (2) have applications in audio and are a part of many computer music languages, synthesizers, and audio processing systems. Examples where (1) exponential ramps are especially important are playback rates and filter frequencies. For example, if changing the playback rate from one octave lower to one octave higher the playback rate changes from 0.5x -> 2x. So in order to make the pitch sound like it's increasing at a constant rate, you need to use an exponential ramp from 0.5 -> 2. In another example using filter frequency, we may want to sweep a resonant filter from 20 hertz to 2000 hertz using an exponential ramp so that the filter *sounds* like it's smoothly moving through the frequencies at a constant rate. That's how human perception works. But (1) requires a non-zero starting value. This is quite simply the way the math works for this shape. If the value is zero, then the exponential increase never has a chance to "take-off" and remains at zero, since any value times zero still equals zero. ChrisReceived on Monday, 12 December 2011 01:59:27 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:49:57 UTC
*