Re: De-zippering and the fundamental issue of target users

> Have you (generic you, not you, Joe) actually encountered a problem with
dezippering

To me it's kind of an irrelevant question as 1) there hasn't been any "real
big" projects made with web audio API so it's hard to have hindsight on
this, and 2) I believe Lonce is more talking about the target group of the
spec, so it's a higher level discussion than just implementation details.


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

> The only place I've seen a problem with dezippering has been in setting
> frequency - the built-in dezippering is too slow, and you can hear an
> audible portamento effect.
>
>
> On Thu, Nov 14, 2013 at 11:22 AM, Raymond Toy <rtoy@google.com> wrote:
>
>> A general question: Have you (generic you, not you, Joe) actually
>> encountered a problem with dezippering?  WebKit and Blink have been doing
>> this for years now, so has dezippering been a problem?
>>
>> It doesn't count if you just cooked up an example specifically to show
>> how dezippering got in the way. :-)
>>
>>
>> On Sun, Nov 10, 2013 at 8:23 AM, Joseph Berkovitz <joe@noteflight.com>wrote:
>>
>>> +1, and just one more angle on this — by way of an analogy.
>>>
>>> How would web developers feel if visual animation was applied by default
>>> for all changes in HTML geometry, and they had to set some special property
>>> in order to “really mean it” when they moved or resized an HTML element?
>>>
>>> Yes, animated motion usually looks better than a jump for many simple
>>> cases. But this doesn't make it a good idea to bake animation into the CSS
>>> API. And in fact, sure enough (even before CSS3 made it easier) users were
>>> perfectly happy with using JS middleware, i.e. jQuery, to get animated
>>> motion.
>>>
>>> Dezippering is no different. It’s a type of animation, but in the
>>> audible realm. Sometimes you want it, sometimes not. When you do want it,
>>> there are a lot of fussy, context-dependent conditions governing where and
>>> how it is used. We should not be guessing at these very un-obvious
>>> conditions (e.g. prescribing that gain should have it but playbackRate
>>> shouldn’t, etc.).
>>>
>>> So I continue to agree with the De-dezipperers. Let’s make this
>>> something that’s easy to do… if you want it. It doesn’t belong in the spec.
>>>
>>>    .            .       .    .  . ...Joe
>>>
>>> *Joe Berkovitz*
>>> President
>>>
>>> *Noteflight LLC*
>>> Boston, Mass.
>>> phone: +1 978 314 6271
>>>   www.noteflight.com
>>> "Your music, everywhere"
>>>
>>> On Nov 9, 2013, at 3:34 AM, s p <sebpiq@gmail.com> wrote:
>>>
>>> 100% agree with K. Gadd
>>>
>>> > Sure, if you're wanting to develop an 8-bit-style game, you'll
>>> probably use a library; If you're just loading music tracks and sound
>>> effects, I don't see that much benefit to imposing someone else's structure.
>>>
>>> Wrong. Why don't you just try an audio middleware, and see what sound
>>> designers are actually doing in real-file? They almost never "just load a
>>> sound effect". One of the most basic example is a motor noise in a car
>>> game. How do you think this is implemented? You have a several sounds to
>>> which you apply filters/pitching/... and all those parameters are modulated
>>> according to the speed of the car in the game. And that's just a simple
>>> example of automation.
>>> For the complicated example : now it is more and more common to do
>>> generative music in games, simply because it is the most natural thing to
>>> do. "Just loading a sound track" is inherently linear, cause the soundtrack
>>> has a beginning and an end, while many games are really not linear, and
>>> generative music feels much more natural.
>>>
>>>
>>>
>>>
>>
>


-- 

*Sébastien Piquemal*

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