Re: De-zippering

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