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

Re: Web Audio API sequencer capabilities

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Mon, 8 Oct 2012 22:30:48 +0300
Message-ID: <CAJhzemXRr4ePiLxQ61L71OS7NRRgxuTag_yevGdds+yy0Km=3g@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, Joe Berkovitz <joe@noteflight.com>, "public-audio@w3.org Group" <public-audio@w3.org>
I agree. I also agree with it being way too complicated for a lot of use
cases to completely move the scheduling out of AudioParam.

But I really like Joe's idea, maybe we should have something called
DCSourceNode which has a voltage param? :P That would definitely address my
use case.

Cheers,
Jussi

On Mon, Oct 8, 2012 at 10:20 PM, Chris Rogers <crogers@google.com> wrote:

>
>
> On Fri, Oct 5, 2012 at 9:03 PM, 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.
>>
>>
> Hi Kumar, I think it's best to keep the AudioBufferSourceNode API simpler.
>  It's only two or three more lines of JS to create the AudioGainNode and
> connect it.
>
>
Received on Monday, 8 October 2012 19:31:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC