Re: De-zippering

Raaa ... here I am complaining again. Sorry :) I'll stop right now.


2013/11/7 s p <sebpiq@gmail.com>

> > "Anybody who has a little bit of experience in handling audio" is not
> our (entire) market.
>
> Unfortunately. To me that's were the "direction" I mentioned earlier is
> wrong. Because in the end it is not developers who do the sound. So they
> shouldn't be the ones to care about these kind of issues. The sound
> designer knows about this problem, and he'll be the one dealing with this.
>
>
> 2013/11/7 Chris Wilson <cwilso@google.com>
>
>> I'm going to express an opinion,  too.  :)  Actually, two of them:
>> 1) "Anybody who has a little bit of experience in handling audio" is not
>> our (entire) market.  Many web developers will never have heard of this.
>> 2) Advisory notes will have no impact on this problem, because this will
>> be buried down thirty pages in to the spec.  A new-to-Web-Audio web
>> developer won't read through that, they'll just wonder why their audio
>> sounds grungy.
>>
>> sp: yes, you can schedule brutal changes with setValueAtTime - you can
>> today.  The issue is what happens with .value.
>>
>> I'm starting to think the best way to fix this, actually, is to expose a
>> "dezippering" property on AudioParam, that defaults to on but 1) makes it
>> obvious what's happening, and 2) makes it easy to turn off.
>>
>>
>> On Thu, Nov 7, 2013 at 11:09 AM, Joseph Berkovitz <joe@noteflight.com>wrote:
>>
>>> This feels like a good time to throw out opinions, so…
>>>
>>> I understand Chris R’s rationale, but like Marcus I think the automatic
>>> dezippering was a mistake and will lead to the kind of impossible decisions
>>> that Chris W is starting down, about where it makes or doesn’t make sense.
>>> We’ll probably never agree on those issues because there are equally valid
>>> arguments for any given configuration of dezippering-or-not.
>>>
>>> So I would rather see the default behavior be no dezippering, and go the
>>> advisory-note route of recommending the use of exponentialRampAtTime().
>>> Additionally, we might provide a simplified version of the latter function
>>> that has the semantics (but not the ugly name) of setDezipperedValue().
>>>
>>> On Nov 7, 2013, at 1:23 PM, Chris Wilson <cwilso@google.com> wrote:
>>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>>          .            .       .    .  . ...Joe
>>>
>>> *Joe Berkovitz*
>>> President
>>>
>>> *Noteflight LLC*
>>> Boston, Mass.
>>> phone: +1 978 314 6271
>>>        www.noteflight.com
>>> "Your music, everywhere"
>>>
>>>
>>
>
>
> --
>
> *Sébastien Piquemal *
>
>  -----* @sebpiq*
>  ----- http://github.com/sebpiq
>   ----- http://funktion.fm
>



-- 

*Sébastien Piquemal*

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