W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: linear ramps and the Web Audio API

From: Phil Burk <philburk@mobileer.com>
Date: Tue, 07 Feb 2012 17:57:01 -0800
Message-ID: <4F31D66D.6000104@mobileer.com>
CC: public-audio@w3.org
Hello Chris,

On 2/7/12 1:04 PM, Chris Rogers wrote:
> The time is a target time and the value is the ramp's end value.  One
> thing that I haven't made clear in the specification is that the
> intended use to first call setValueAtTime() to establish the initial
> (value,time).  Then subsequent calls to linearRampToValueAtTime()
> or exponentialRampToValueAtTime() can be made, and even chained one
> after the other.

Ahah!  I tried that and it worked much better. I now get smooth 
envelopes.  THANKS for the tip.

> One case I probably haven't handled which I think
> you're trying to test is how to call linearRampToValueAtTime() to
> establish the end-point of the linear ramp, but where you don't know
> what the starting value is (so a call to setValueAtTime() would not be
> possible).

Exactly. One might, for example, want to schedule some ramps in response 
to a user input. The current value may be unknown.

> Instead, in this case, we would want to start ramping from
> *whatever* value the parameter is "currently at".

As a workaround I do:

   var now = context.currentTime;
   gainNode.gain.cancelScheduledValues( now );
   // Anchor beginning of ramp at current value.
   gainNode.gain.setValueAtTime(gainNode.gain.value, now);

before I start scheduling the next series of ramps. I am probably 
getting small glitches because the ramp changes between the get and set. 
But it sounds much better than before.


> perhaps we need something like:
> void anchorValueAtTime(in float time);
> This would simply take whatever the current value is of the parameter at
> the given time and establish it as the anchor point (startValue,
> startTime) for a subsequent call to linearRampToValueAtTime(endValue,
> endTime) or exponentialRampToValueAtTime.

Yes. I think that would solve the problem and integrates well with the 
existing API.

Thanks for your help!

Phil Burk
Received on Wednesday, 8 February 2012 02:01:13 UTC

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