- From: K. Gadd <kg@luminance.org>
- Date: Fri, 8 Nov 2013 13:33:05 -0800
- To: Chris Wilson <cwilso@google.com>
- Cc: Marcus Geelnard <mage@opera.com>, Lonce Wyse <lonce.wyse@zwhome.org>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAPJwq3U1c44UU=CRJ+3hJQeWMVhdjJHiDWL7ZxUZnR7YFquWiQ@mail.gmail.com>
I don't think whether a maintainer finds a library incredibly easy to use really counts for anything. ;) Aside from whether or not Web Audio is easy to use, didn't we learn with ScriptProcessorNode that leaning too heavily towards baking special-case 'make everything easy' behaviors and components into the library can distract from the important task of providing solid low-level primitives? I don't know if dezippering is one of those cases, but it does seem like something optional that can be solved by higher-level abstractions, and something that isn't so complex that it needs to be specified into the API. Speccing it as part of Web Audio seems particularly risky since it is not 'obvious' which values should be dezippered and which paths for setting values should be dezippered. If a newbie comes in and uses Web Audio and only *sometimes* gets dezippering, based on a rather arbitrary selection of which mechanism(s) they use to set parameter values (when those mechanisms LOOK like they should do effectively the same thing), I do not think that is a good situation. I think that will confuse them and undermine their trust in the API. If dezippering is introduced, it should only apply to value-setting mechanisms that make it exceedingly clear that they are different from other mechanisms for setting values, by having a cue in the name or something like that. If Web Audio implementations ship without dezippering, the resulting artifacts will be the same as you'd get in any other library without them (a common scenario), and a newbie can search google for articles about how to address that problem. If they're lucky, they'll find articles about how to do dezippering with Web Audio. Also, to be quite honest, I think the nature of the problem (and the solution) is relatively obvious to anyone who thinks about it in particular for long enough - if you educate them a little, the users who care will be able to figure it out. Users who don't care won't care either way. "If you're just loading music tracks and sound effects, I don't see that much benefit to imposing someone else's structure." actually applies as much as a critique of Web Audio as it does to anything else in this discussion. Web Audio already imposes an excess of structure in an attempt to... do something, I'm not sure exactly what. That structure is useful at a larger scale, but it certainly does not provide as much value for the common, simple cases. On Fri, Nov 8, 2013 at 8:56 AM, Chris Wilson <cwilso@google.com> wrote: > I actually find Web Audio incredibly easy to write to, and I think it is a > wild disservice to developers to presume that we don't need to make it > particularly easy for them. 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. > > > On Fri, Nov 8, 2013 at 12:31 AM, Marcus Geelnard <mage@opera.com> wrote: > >> 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> >> >>> 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> >>> >>>> 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 >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> *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 21:34:13 UTC