Re: Hi all.

Den 2012-11-21 14:26:03 skrev Chris Wilson <cwilso@google.com>:

> 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.

I fail to find any mention of de-zippering of the value attribute in the  
AudioParam spec.

For the AudioGain node there is still the somewhat vague sentence "The  
implementation must make gain changes to the audio stream smoothly,  
without introducing noticeable clicks or glitches" (see bug 17339 ). It  
only applies to AudioGain though, and to me it sounds as if it should  
apply to all kind of events, including setValueAtTime.

/Marcus


>
>
> 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.
>>
>>
>>
>



-- 
Marcus Geelnard
Core graphics developer
Opera Software ASA