Re: Consensus gathering for the Dezippering issue

On Tue, Dec 3, 2013 at 1:34 PM, Karl Tomlinson <
> wrote:

> Chris Lowis writes:
> >  3) Define it in terms of one of the other methods (probably
> > exponentialRampToValueAtTime) to simplify the spec and also to
> > indicate to developers how to achieve parameter changes without
> > dezippering by using those methods directly.
> If the initial value is zero, then IIUC
> exponentialRampToValueAtTime() would be a step function at the
> endTime (even though the spec doesn't permit 0 or negative
> values)?
> If the final value is zero, then it would be a step function at
> the initial time?
> We'd need a different function for values that could be negative.

Probably wanted  setTargetAtTime instead of exponentialRampToValueAtTime.
setTargetAtTime is, essentially, dezippering.  (Yes, I confuse the two all
the time.)


> There is also the problem that there isn't a way to specify the
> duration of an effect starting ASAP using the current AudioParam
> methods.  The best way I found to do that was to start another
> AudioBufferSourceNode with the shape of the curve and connect it
> to the AudioParam. [1]
> [1]

Received on Wednesday, 4 December 2013 00:29:14 UTC