Unclear behavior of setTargetAtTime when there is an event following setTargetAtTime

[rtoy]

In http://webaudio.github.io/web-audio-api/#widl-AudioParam-setTargetAtTime-void-float-target-double-startTime-float-timeConstant, there is the paragraph

During the time interval: T0≤t<T1, where T0 is the startTime parameter and T1 represents the time of the event following this event

While this behavior would actually be nice, it is inconsistent with how linear and exponential ramps are defined. If such an event were scheduled at time T1, then the ramp would effectively replace the setTargetAtTime event at time T0. This is the behavior on Chrome and Safari.

The spec should probably be changed to say the time interval is T0 <= t.

[rtoy]

The behavior is really confusing and sometimes quite different between Chrome and Firefox (the two browsers I have handy).

Consider this:

gain.gain.value = 0.5;
gain.gain.setTargetAtTime(0, 0.1, 0.1);
gain.gain.setTargetAtTime(1, 0.2, 0.1);

On Chrome, this does what I expect. At time 0.2, setTargetAtTime ramps up to 1, starting at wherever the first setTargetAtTime left off. Firefox jumps up at 0.2 to the value 0.5 and ramps up to 1.

Consider this:

gain.gain.value = 0.5;
gain.gain.setTargetAtTime(0, 0.1, 0.1);
gain.gain.setTargetAtTime(1, 0.2, 0.1);
gain.gain.linearRampToValueAtTime(3, 0.5);

With Chrome, at time 0.5, the curve jumps up to 1, and then we get a linear ramp to 3. Firefox does something different. setTargetAtTime starts at time 0.2, runs to time 0.5, ramping up as usual, and then at time 0.5 jumps to 3.

(It's really easy to visualize these if you use https://hoch.github.io/canopy)

For the second case, I don't actually like the behavior of either browser.

I haven't investigated what happens if a setTarget is already being processed when you add a linear ramp. To do that, you need a browser that supports suspend/resume on offline contexts. (Coming soon on Chrome.)

[karlt]

rtoy writes:

The behavior is really confusing and sometimes quite different between Chrome
and Firefox (the two browsers I have handy).

Consider this:

gain.gain.value = 0.5;
gain.gain.setTargetAtTime(0, 0.1, 0.1);
gain.gain.setTargetAtTime(1, 0.2, 0.1);

On Chrome, this does what I expect. At time 0.2, setTargetAtTime ramps up to
1, starting at wherever the first setTargetAtTime left off.

Sounds good.

Firefox jumps up at 0.2 to the value 0.5 and ramps up to 1.

Sounds like a bug, unless this is based on some previous
interpretation of "the .value attribute".

Chrome's behavior seems more useful and consistent with the spec today.

Consider this:

gain.gain.value = 0.5;
gain.gain.setTargetAtTime(0, 0.1, 0.1);
gain.gain.setTargetAtTime(1, 0.2, 0.1);
gain.gain.linearRampToValueAtTime(3, 0.5);

With Chrome, at time 0.5, the curve jumps up to 1, and then we get a linear
ramp to 3. Firefox does something different. setTargetAtTime starts at time
0.2, runs to time 0.5, ramping up as usual, and then at time 0.5 jumps to 3.

I think the useful behavior would be that the linearRamp curve
overrides the second setTarget curve, but the second setTarget
still provides the start point for the linearRamp. i.e. at time
0.2, the value increases linearly, from where the first
setTargetAtTime reached, to 3 at 0.5.

AFAIK the spec is not clear on the appropriate behavior.

[rtoy]

On Thu, Nov 19, 2015 at 3:32 PM, Karl Tomlinson notifications@github.com
wrote:

rtoy writes:

The behavior is really confusing and sometimes quite different between
Chrome
and Firefox (the two browsers I have handy).

Consider this:

gain.gain.value = 0.5;
gain.gain.setTargetAtTime(0, 0.1, 0.1);
gain.gain.setTargetAtTime(1, 0.2, 0.1);

On Chrome, this does what I expect. At time 0.2, setTargetAtTime ramps
up to
1, starting at wherever the first setTargetAtTime left off.

Sounds good.

Firefox jumps up at 0.2 to the value 0.5 and ramps up to 1.

Sounds like a bug, unless this is based on some previous
interpretation of "the .value attribute".

Chrome's behavior seems more useful and consistent with the spec today.

Consider this:

gain.gain.value = 0.5;
gain.gain.setTargetAtTime(0, 0.1, 0.1);
gain.gain.setTargetAtTime(1, 0.2, 0.1);
gain.gain.linearRampToValueAtTime(3, 0.5);

With Chrome, at time 0.5, the curve jumps up to 1, and then we get a
linear

​Typo: What happens is at time 0.2, the curve jumps to 1 (the target value
of setTargetAtTime).
​

ramp to 3. Firefox does something different. setTargetAtTime starts at
time
0.2, runs to time 0.5, ramping up as usual, and then at time 0.5 jumps
to 3.

I think the useful behavior would be that the linearRamp curve
overrides the second setTarget curve, but the second setTarget
still provides the start point for the linearRamp. i.e. at time
0.2, the value increases linearly, from where the first
setTargetAtTime reached, to 3 at 0.5.

​That is what I would like too; it seems much more useful.

However, consider this case

gain.gain.value = 0.5
gain.gain.setTargetAtTime(0, 0.1, 0.1);
<wait until time 0.1 has passed>
gain.gain.linearRampToValueAtTime(10, ​
​currentTime + 1)

What chrome does is the setTarget is running and at the time of the linear
ramp, the curve jumps up to the value it would have had if the setTarget
had never run, but a setValueAtTime(0, 0.1) were there in place of
setTarget.

Don't know what Firefox does in this case (need suspend/resume to test
reliably).

​

—
Reply to this email directly or view it on GitHub
#652 (comment)
.

Ray

[karlt]

rtoy writes:

However, consider this case

gain.gain.value = 0.5
gain.gain.setTargetAtTime(0, 0.1, 0.1);
<wait until time 0.1 has passed>
gain.gain.linearRampToValueAtTime(10, ​
​currentTime + 1)

What chrome does is the setTarget is running and at the time of the linear
ramp, the curve jumps up to the value it would have had if the setTarget
had never run, but a setValueAtTime(0, 0.1) were there in place of
setTarget.

This is similar to option 1 of
#573 (comment)

I expect it would be more helpful to have a continuous curve by
beginning the linear ramp from the value the setTarget curve
reached at the time when linearRampToValueAtTime() is called,
which would correspond to option 2.

[rtoy]

On Thu, Nov 19, 2015 at 5:44 PM, Karl Tomlinson notifications@github.com
wrote:

rtoy writes:

However, consider this case

gain.gain.value = 0.5
gain.gain.setTargetAtTime(0, 0.1, 0.1);
<wait until time 0.1 has passed>
gain.gain.linearRampToValueAtTime(10, ​
​currentTime + 1)

What chrome does is the setTarget is running and at the time of the
linear
ramp, the curve jumps up to the value it would have had if the setTarget
had never run, but a setValueAtTime(0, 0.1) were there in place of
setTarget.

This is similar to option 1 of
#573 (comment)

I expect it would be more helpful to have a continuous curve by
beginning the linear ramp from the value the setTarget curve
reached at the time when linearRampToValueAtTime() is called,
which would correspond to option 2.

​I think this makes the most sense. Linear and exponential ramps preceded
by a setTarget will start the ramp at whatever point of the setTarget curve
is current when the linear/expo ramps start.

So, if the setTarget hasn't started, the linear ramp starts at the start
value of the setTarget (chrome uses the target value!).

This is what I would like to propose.​

This also fixes a use case @hongchan mentioned to me where you're decaying
a sound and the user presses a key again so you want to do a linear ramp
attack, starting at wherever the setTarget was at at the key press.

—
Reply to this email directly or view it on GitHub
#652 (comment)
.

Ray