Re: De-zippering

Sure, a game developer is likely not programming the sounds himself.  But I
absolutely guarantee that a developer (i.e. non-sound-designer-type-person)
will be implementing a volume control slider that's hooked up to a gain
node's .value, and similar things.


On Thu, Nov 7, 2013 at 1:20 PM, s p <sebpiq@gmail.com> wrote:

> yes ... but my point is that in real life projects, the developers are not
> doing the sound design, and probably shouldn't because it's hard enough to
> be a good developer.
> And 99% sound designers cannot code, and they probably shouldn't. It is
> hard enough to be a good sound designer.
>
> It reminds me of a game audio workshop I attended a while ago. First
> examples of game audio were some horrible early 8bits tunes, and the joke
> was that at the time the developer was doing the whole thing, including
> composing the music himself.
> Providing this kind of high-level features on such a low-level, just to
> make up for the user's lack of knowledge in the topic is kind of taking the
> same perspective that the developer is going to do everything, like back in
> the early 80s.
>
>
> 2013/11/7 Chris Wilson <cwilso@google.com>
>
>> New developers come along all the time, though, and it's not illogical to
>> consider that in the future, there will be sound designers who cut their
>> sound design teeth on Web Audio.  How are they going to learn about this?
>>
>>
>> On Thu, Nov 7, 2013 at 11:39 AM, s p <sebpiq@gmail.com> wrote:
>>
>>> > "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
>