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

2013-11-07 23:02, Lonce Wyse skrev:
>
> Dear All,
>
>     I think the issue is really one of target users which has not 
> really been articulated well.
>     My own feeling is that the vast majority of web, music, and game 
> developers who will benefit from the new capabilities aren't going to 
> be writing much Web Audio API code themselves, and will instead be 
> using libraries, frameworks, sounds, etc. developed by "power users" 
> of the API. The implication is that the API should be providing raw 
> capability, and leaving the "make it easy for people" task to 
> "middleware" developers.

+1

/Marcus

>
> - lonce
>
>
>
> On 11/7/2013 7:31 PM, s p wrote:
>> + anybody that has a little bit experience in handling audio knows 
>> about this problem.
>>
>>
>> 2013/11/7 s p <sebpiq@gmail.com <mailto:sebpiq@gmail.com>>
>>
>>     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 <mailto: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 <mailto: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
>>
>>
>>
>>
>> -- 
>> *Sébastien Piquemal
>> *
>> *
>> ***-----*@sebpiq*
>>  -----**http://github.com/sebpiq*
>> *
>> ----- http://funktion.fm
>


-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software

Received on Friday, 8 November 2013 08:32:20 UTC