W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: Web Audio API sequencer capabilities

From: Joseph Berkovitz <joe@noteflight.com>
Date: Sat, 6 Oct 2012 11:57:08 -0400
Cc: Chris Rogers <crogers@google.com>, Joe Berkovitz <joe@noteflight.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org Group" <public-audio@w3.org>
Message-Id: <A4A3995F-E35A-431A-95E0-0E98EC5A3A3A@noteflight.com>
To: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
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.


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

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271

Received on Saturday, 6 October 2012 15:57:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC