W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: Arithmetic Nodes

From: Chris Wilson <cwilso@google.com>
Date: Mon, 1 Jul 2013 08:25:05 -0700
Message-ID: <CAJK2wqUg6_CgWAXZpu1z1sMW+RqP4QCE4rm42oSMZkVqhdzjgQ@mail.gmail.com>
To: Chris Lowis <chris.lowis@bbc.co.uk>
Cc: Marcus Geelnard <mage@opera.com>, WebAudio <public-audio@w3.org>
Actually, I think ScriptProcessorNodes are overkill here.  We actually have
not only addition (summing-on-input), multiplication (routing audio-rate
input into GainNode's input AND .gain), subtraction (summing-on-input with
a GainNode.gain.value = -1 added in the path) but even comparison can be
done (WaveShaper providing a 0/1 switch).  I'm not sure of the utility of
division (i.e. "when would a developer use this?"), but I might just be
missing an easy way to do it.

If we were adding more node types to the spec, I'd rather look at some of
the areas where we can't replicate behavior without a ScriptProcessorNode -
for example, cracking open the DynamicsProcessor to provide a generically
useful envelope follower with threshold, attack, release and hysteresis
controls, enabling noise gating, sidechain compression, autowah*, etc.  I
think at this point it's probably best to lock down the feature set of Web
Audio 1.0, though.  (Some issues, like
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20698, I still think are
critical, of course.)

-C

*You may note I figured out how to do an autowah in the Input Effects demo
- the problem is it's a straight envelope follower, with no attack/release
controls.  I implemented a noise gate using the same technique, but it's
nearly useless - you can easily hear the threshold crossing, and the
"pumping" as it kicks in and out.



On Mon, Jul 1, 2013 at 7:58 AM, Chris Lowis <chris.lowis@bbc.co.uk> wrote:

>
> Marcus Geelnard writes:
> > I really think that ScriptProcessorNodes are sufficient for these kind
> > of operations. If they are considered too heavy, I think that arithmetic
> > nodes could built on top of them (it should be easy enough to do it as a
> > JS lib).
>
> I'm sure you're right here. However, I noticed with languages like pure
> data these operations are so fundamental that they're available as
> independent "nodes". One advantage of making them available as "native"
> nodes would be to avoid the additional latency added when using a
> ScriptProcessorNode.
>
> Cheers,
>
> Chris
>
>
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------
>
Received on Monday, 1 July 2013 15:25:34 UTC

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