- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Mon, 8 Oct 2012 22:41:13 +0300
- To: Chris Rogers <crogers@google.com>
- Cc: Joseph Berkovitz <joe@noteflight.com>, Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, "public-audio@w3.org Group" <public-audio@w3.org>
- Message-ID: <CAJhzemW5ytCnBhx3aJj8Jvd6EE6FT9t6akK9DfJEkneXjXLCaQ@mail.gmail.com>
Actually, on second thought I agree. On Mon, Oct 8, 2012 at 10:33 PM, Chris Rogers <crogers@google.com> wrote: > > > On Sat, Oct 6, 2012 at 8:57 AM, Joseph Berkovitz <joe@noteflight.com>wrote: > >> Hi Kumar, >> >> While I think a single-node solution to this use case would be nice, >> overall I agree with the removal of the gain parameter from >> AudioBufferSourceNode. I fear that it leads to a slippery slope in which >> more and more bells and whistles get stuffed into that interface. >> >> If we extend the API in this direction in the future, rather than restore >> gain to ABSN, I would rather see a new type of node with an AudioParam >> driving its constant value. Such a node's only function is to emit a >> parameter-driven value. In essence it's no more than a Node wrapping an >> AudioParam -- in fact, it could be named AudioParamSourceNode, by analogy >> with AudioBufferSourceNode. Such a node can serve as both a unity source, >> a non-unity source, an envelope, or whatever. >> >> > But this is so easy to create already. I understand that it might save > two or three lines of JS code, but that doesn't seem worth the effort to > specify a whole new node. > > > >> …j >> >> On Oct 6, 2012, at 12:08 AM, Srikumar Karaikudi Subramanian < >> srikumarks@gmail.com> wrote: >> >> Sorry, I messed up reading dates (the gain param was removed on 11 Apr >> 2012), but the overall point is valid I think. >> >> Best, >> -Kumar >> >> On 6 Oct, 2012, at 9:33 AM, Srikumar Karaikudi Subramanian < >> srikumarks@gmail.com> wrote: >> >> On 6 Oct, 2012, at 4:27 AM, Joe Berkovitz <joe@noteflight.com> wrote: >> >> Actually, I didn't ever think a GainNode would generate its own signal. >> Rather, it did not occur to me to drive a set of AudioParams with an >> envelope via the audio rate modulation feature, using a gain controlled >> unity signal. It is this last idea that seems a bit tricky and unclear for >> API novices. If there were something like a UnitySourceNode, I would feel >> better. >> >> Chris R - I see that the AudioBufferSourceNode's 'gain' attribute was >> removed from the spec in Apr '11 ( >> https://dvcs.w3.org/hg/audio/file/908b6b7b8702/webaudio/specification.html), >> but it is present in all webkit implementations even today, including >> Chrome Canary. In >> http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0072.html, >> you wrote -- "We may need to re-visit the removal of these gain >> attributes from the API, since I've found several pages out in the wild >> using them. They're not harmful attributes, just ones I felt could be >> cleaned up (removed) since AudioGainNode can be used instead. We may need >> to choose a deprectation path, or simply keep them." >> >> With the 'gain' parameter, the AudioBufferSourceNode would offer a single >> node solution to envelope generation. You can set a one sample buffer with >> sample value = 1, turn on looping and work with its gain parameter. This is >> simple enough that a special UnitySourceNode and an EnvelopeNode would be >> superfluous. (I only just realized I've been using the ABSN this way >> instead of the "GainNode with unity signal" approach I mentioned earlier .. >> but was surprised to find that the ABSN.gain parameter was removed from the >> spec.) >> >> AudioBuffer.gain and AudioListener.gain are likely to be superfluous, but >> if AudioBufferSourceNode.gain is removed, a gain node seems likely to be >> necessary most of the time anyway. Given that the ability to connect a node >> to an AudioParam didn't exist when the ABSN.gain parameter was removed, it >> is worth reconsidering it in the context of envelopes as well. >> >> Best, >> -Kumar >> >> >> >> ... . . . Joe >> >> *Joe Berkovitz* >> President >> >> *Noteflight LLC* >> Boston, Mass. >> phone: +1 978 314 6271 >> www.noteflight.com >> >> >
Received on Monday, 8 October 2012 19:41:40 UTC