W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2014

Re: Fading sound in and out

From: Norbert Schnell <Norbert.Schnell@ircam.fr>
Date: Tue, 26 Aug 2014 22:14:56 +0200
Cc: public-audio@w3.org
Message-Id: <42DDDAD2-0AEF-4E30-B158-2DC93C2B5F52@ircam.fr>
To: "Ray Bellis" <ray@bellis.me.uk>

On 26 Aug 2014, at 21:45, "Ray Bellis" <ray@bellis.me.uk> wrote:
>> What I would expect is that calling the function "linearRampToValueAtTime"
>> would use the current value at current time as a start point and ramp from
>> there to the given value at the given time. In that case the fade times
>> are always respected (even though the slopes wouldn't).
>> I could not think of any scenario in which this behaviour would not be
>> desired, do you?
> 
> See endless threads passim where it has been noted that for an ADSR EG it
> is the slope that's most important.

Well, I don't think that the slope is worth a lot in a env if you generate a click right before it.
 and if you want to control the slope you always can use "setValueAtTime" and even "cancelScheduledValues".

(I find it just a pity that one needs to call functions that "cancel" and "set" to generate continuous envelopes while "ramp" may generate discontinuities.)

> Consequently to maintain that slope you must somehow both determine the
> current value of the EG (if non-zero) and the amount of time you expect
> the EG to take to go from that value to the new value.

Can that be something like this?

  var now = audioContext.currentTime;
  var currentValue = myParam.value;

  myParam.cancelScheduledValues(now);
  myParam.setValueAtTime(currentValue, now);

  var duration = targetValue / slope;
  // or: var targetValue = duration * slope;

  myParam.linearRampToValueAtTime(targetValue, now + duration);

N.
Received on Tuesday, 26 August 2014 20:15:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC