Re: Consensus gathering for the Dezippering issue

On Tue, Dec 3, 2013 at 1:34 PM, Karl Tomlinson <karlt+public-audio@karlt.net
> 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.)

Ray




> 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] https://bugzilla.mozilla.org/show_bug.cgi?id=943138#c8
>
>