Re: De-zippering

What about if you want - on purpose - to create a pop by brutally changing
a gain value? I have used his technique to do some glitch-like percussions,
or sound effects like vinyl crackling sound.

+ that has a little bit experience in handling audio knows about this
problem.


2013/11/7 Chris Wilson <cwilso@google.com>

> Chris (Rogers)' reasoning behind implementing this way to begin with was
> that most users simply don't know about this at all.
>
> My personal feeling on this is that there are some scenarios that
> automatically applying dezippering on makes sense, and some it does not.
>  For example, it would make sense to dezipper volume control; however, it
> does not make sense to dezipper frequency control.  This leads me to think
> that it might be good to apply to gain.gain.value, but not to
> oscillator.frequency.value, for example.
>
>
> On Thu, Nov 7, 2013 at 3:51 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>> 2013-11-07 12:23, Chris Lowis skrev:
>>
>>  Hi!
>>>
>>> There's a task for me to look into how "dezippering" is performed in
>>> Webkit and to explain how and why we do it.
>>>
>>> I've put together a quick demo to show the effect of dezippering
>>>
>>> http://blog.chrislowis.co.uk/demos/dezippering/
>>>
>>> And made some notes on how it is implemented on this ticket:
>>>
>>> https://github.com/WebAudio/web-audio-api/issues/76
>>>
>>> I think it's open for debate whether we clarify dezippering (I think
>>> I'd prefer to use the term "parameter smoothing") in the spec, and all
>>> of the parameters to which it applies by default, or whether we move
>>> to remove mention of it altogether and perhaps add an advisory note
>>> about preventing glitches by using exponentialRampToValueAtTime() for
>>> example.
>>>
>>> For that reason, I haven't prepared a PR. Perhaps we can discuss it
>>> here first and I can prepare one later.
>>>
>>
>> In general I prefer not to have too much magic going on behind the scenes.
>>
>> The automatic smoothing (dezippering) in Web Audio reminds me of when
>> progress bar smoothing logic was added to Windows Vista. In an attempt to
>> create a more pleasant experience for the user, the new implementation left
>> developers unable to control the progress bar the way they wanted to [1]
>> (e.g. reaching 100% progress was almost impossible without fooling the API
>> by utilizing known quirks in the underlying progress bar smoothing
>> implementation).
>>
>> Let's not repeat that mistake. Unless there are strong use cases for
>> automatic parameter smoothing that can not be handled using explicit
>> interfaces, I'd prefer dropping it in favor of explicit interfaces.
>>
>> /Marcus
>>
>>
>>
>> [1] http://stackoverflow.com/questions/1061715/how-do-i-
>> make-tprogressbar-stop-lagging
>>
>>
>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>
>>
>> --
>> Marcus Geelnard
>> Technical Lead, Mobile Infrastructure
>> Opera Software
>>
>>
>>
>


-- 

*Sébastien Piquemal*

 -----* @sebpiq*
 ----- http://github.com/sebpiq
 ----- http://funktion.fm