Re: Hi all.

I ran into this recently too.  It's due to dezippering in .value.  The way
to avoid it is instead of setting AudioParam.value, call
AudioParam.setValueAtTime( value, audiocontext.currentTime ).
 setValueAtTime is not dezippered.


On Tue, Nov 20, 2012 at 12:29 PM, redman <redman@redman.demon.nl> wrote:

> Hello everyone.
>
> I've recently become involved in a web audio API project (so this is
> directed at the people involved in defining this).
> It's a reasonably simple affair with a couple of synths and a drumcomputer.
> But i have run into some strange behaviour from a musical perspective.
> The problem is that apparently when you use  .Value =   to set an
> AudioParam value it is heavily (sloooowly) interpolated.
> Now i understand why you do this but it doesn't make sense to do it all
> the time and it certainly doesn't make sense to not be able to change the
> speed of this interpolator.
>
> One of the problems that occur is when setting the frequency of an
> oscillator.
> What happens is that the frequency will change but it will not be
> instantaneously, so the frequency slides from one value to the next.
> And that is pretty useless as the change is way too slow for most
> situations.
> What does work is just scheduling the change, but this is not always
> wanted and seems counter-intuitive. When i set a value i expect it to just
> change.
> What would be useful is some way to either disable this behavior or to be
> able to control the speed of interpolation.
> In the case of oscillator frequency it actually represents an optional
> function usually called Portamento.
> And of course in real synths this function can be switched off or tweaked
> to fit the sound designers intention.
> But in the implementation (chrome) that i use it is neither optional nor
> configurable which is a bad thing and actually unwanted most of the time.
> If you think it's great because getting rid of clicks gave you a free
> portamento think again! :)
> It is just not always appropriate to have this behaviour and fixing it
> globally is like looking at the world through a hammer. Everything becomes
> a nail.
>
> So i hope you can fix that in the future. Not all modulations are meant to
> be used with smooth continuous signals!
> Preferably there would be separate functions to have the input either
> interpolated or not. That way you can simultaneously input values that you
> want to be interpolated and values that you do not want to become
> interpolated and they would be mixed together down the path before feeding
> the actual audio algorithm.
> Also, there may be a future need to decide the actual interpolation algo
> because not all types of interpolation work equally well on all parameter
> types.
> But first things first :) make it so that it doesn't stand in the way of
> building great synths.
>
> greets,
> aka.
>
>
>
>