AudioParam setter does not work after the execution of automation.

[hoch]

This is something to think about - I don't think this behavior is clearly specified. What happens if the setter is used after cancelScheduledValues() method called?

var context = new AudioContext();
var sine = context.createOscillator();

sine.connect(context.destination);
sine.start();

sine.frequency.setValueAtTime(440.0, 0);
sine.frequency.linearRampToValueAtTime(880.0, 3);
sine.frequency.cancelScheduledValues(3.5);

var freq = 660.0;

function setValue() {
  freq = (freq === 660.0) ? 770.0 : 660.0;
  sine.frequency.value = freq;
  console.log('current time: ' + context.currentTime);  
  console.log('settting frequency: ' + freq);
  setTimeout(setValue, 2000);
}

setValue();

FYI, currently FF and Chromium don't do anything with the setter. Once the automation happens, it locks up the setter for good.

[notthetup]

Hmm! I didn't know this. This might explain a few issues I was noticing with cancelling automation. Locking up the setter seems very unintuitive.

I would expecting a setter call, to internally cancel all automation and then set the value to the argument of the setter.

Otherwise it might make sense to somehow indicate that the setter is locked up after the automation starts.

[rtoy]

Not all is lost, though. setValueAtTime still works and has the same effect as using the setter, except for the de-zippering that might happen. If de-zippering is needed you can use setTargetAtTime with an appropriate time constant.

I think the main issue is what happens to setTargetAtTime automations that are essentially infinite in duration. If it's already started, what does cancelScheduledEvents to with that? Or with any automation that has started but has not stopped yet?

[notthetup]

@rtoy Good point.

I have gotten into a habit of doing this this every time I cancel any automation, because I wasn't sure what was actually happening. I know it's not perfect, but it works.

var currentVal = osc.frequency.value;
osc.frequency.cancelScheduledValues(context.currentTime);
osc.frequency.setValueAtTime(currentVal, context.currentTime);

[rtoy]

Ah, this is a duplicate of issue #128

[hoch]

Just to leave a note about this issue, here's the excerpt from the section 2.5.3:

If the value attribute is set after any automation events have been scheduled, then these events will be removed.

So we remove all the existing events regardless of its start or end time. However, what happens after the removal of automation? De-zippering from the current intrinsic value to the setter value? (sounds a lot like setTargetAtTime() except that the de-zippering duration is fixed.)

We need to decide and specify the behavior for this case.

[joeberkovitz]

Resolution: calling the setter implicitly invokes cancelScheduledValues(), which restores the operation of all further getter/setter calls. Clarify spec as needed.

[hoch]

@rtoy, @cwilso and I discussed this issue a bit more in person, and we agreed that the last decision needs to be revisited.

• Calling the setter should add a value-time point in the timeline with the current time. (= AudioParam.setValueAtTime(value, context.currentTime)) It should not cancel the scheduled automations.
• cancelScheduledValues(t) should stop the automation at t and set a value-time point at t with a computed value of the previous automation at time t.

I guess we still have some open issues in AudioParam, and we should discuss them in the next F2F meeting.

[padenot]

I agree with @hoch, and I think this is something we need to discuss as the f2f indeed.

[joeberkovitz]

Resolution: Merge PR 583, close this issue and #128 and file cancelScheduleValues(t) as a separate issue.

[hoch]

I will try to write up ideas/notes about cancelScheduleValues(t) and send it out to the group.

[hoch]

I did not need to open a new issue: we've already made a decision for cancelScheduledValues(t) at the issue #344.