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

Re: Web Audio API sequencer capabilities

From: Chris Rogers <crogers@google.com>
Date: Mon, 8 Oct 2012 12:33:36 -0700
Message-ID: <CA+EzO0=PtFMxvmxR-KxezsFX+-iphhtjGstCxQNNS9iSJWpV9w@mail.gmail.com>
To: Joseph Berkovitz <joe@noteflight.com>
Cc: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org Group" <public-audio@w3.org>
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:34:04 UTC

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