- From: Lonce Wyse <lonce.wyse@zwhome.org>
- Date: Thu, 07 Nov 2013 23:02:42 +0100
- To: public-audio@w3.org
- Message-ID: <527C0E02.4010507@zwhome.org>
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. - 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
Received on Thursday, 7 November 2013 22:03:41 UTC