Web-audio-api: AudioParam.linearRampToValueAtTime

[pendragon-andyh]

I am currently writing tests for the specification and have found linearRampToValueAtTime does not match my understanding of my spec.

If you do:

    param.value=0;
    param.linearRampToValueAtTime(1, 1);

then Chrome and Firefox both then there is no change until 1 second - when it jumps _instantaniously_ from 0 to 1.

However,

    param.setValueAtTime(0, 0);
    param.linearRampToValueAtTime(1, 1);

then you get a _smooth ramp_ between 0 and 1.

https://github.com/pendragon-andyh/WebAudio-Testing/blob/master/webaudio/the-audio-api/the-audioparam-interface/method-linearRampToValueAtTime.html

@chrislo recommended that I clarify here whether you feel this is a bug or if the specification needs to be amended.

[padenot]

Schedules a linear continuous change in parameter value _from the previous scheduled parameter value to the given value_

(emphasis mine).

If there is no previous event (and keep in mind that setting the value directly is not an event), then we can't interpolate, so we return the previous value.

[cwilso]

The part about "setting the value directly is not an event" is the part
that is confusing. I ran in to this when I started, as well. Perhaps we
should call it out better?

On Mon, Jun 23, 2014 at 7:37 AM, Paul ADENOT [email protected]
wrote:

Schedules a linear continuous change in parameter value _from the
previous scheduled parameter value to the given value_

(emphasis mine).

If there is no previous event (and keep in mind that setting the value
directly is not an event), then we can't interpolate, so we return the
previous value.

—
Reply to this email directly or view it on GitHub
https://github.com/WebAudio/web-audio-api/issues/341#issuecomment-46838891
.

[pendragon-andyh]

I agree. There are 2 distinct usage scenarios. You can use value property
OR you can use the scheduling methods.

I expected setting the value directly to be treated implicitly as
setValueAtTime(x, ac.currentTime).

The problem with audio programming (in general) is that it is difficult to
see when these things don't work intuitively. I only found this issue
because I was writing tests that look very closely at the output.
Previously I just puzzled about why some of my sounds were delayed or had
attack phases that were too fast.

On 23 June 2014 17:28, Chris Wilson [email protected] wrote:

The part about "setting the value directly is not an event" is the part
that is confusing. I ran in to this when I started, as well. Perhaps we
should call it out better?

On Mon, Jun 23, 2014 at 7:37 AM, Paul ADENOT [email protected]
wrote:

Schedules a linear continuous change in parameter value _from the
previous scheduled parameter value to the given value_

(emphasis mine).

If there is no previous event (and keep in mind that setting the value
directly is not an event), then we can't interpolate, so we return the
previous value.

—
Reply to this email directly or view it on GitHub
<
https://github.com/WebAudio/web-audio-api/issues/341#issuecomment-46838891>

.

—
Reply to this email directly or view it on GitHub
https://github.com/WebAudio/web-audio-api/issues/341#issuecomment-46860446
.

[cwilso]

This is a duplicate of #128.

[olsonpm]

I just ran into this exact issue now. I appreciate your guys' explanation of the problem - and would love the docs to make this explicit. What's further confusing is the following exmple seen on the official MDN docs which exhibits the above bug:

docs: https://developer.mozilla.org/en-US/docs/Web/API/AudioParam.linearRampToValueAtTime
example in docs: http://mdn.github.io/audio-param/