Web-audio-api: DynamicsCompressor node should enable sidechain compression

[cwilso]

Side-chain compression (http://en.wikipedia.org/wiki/Dynamic_range_compression#Side-chaining) is a very common and useful music production technique. It's used for ducking (reducing music level while speaking), de-essing, removing plosives, maximizing volume in bass-heavy music, and other techniques.

There are a couple of ways that have been suggested to add this to the Web Audio API: either exposing the reduction as an AudioNode that can be connect()ed to other AudioParams, or exposing a separate input node (with the semantic, presumably, that a separate input node would disable the signal path from the "control" input).

[cwilso]

Really want envelope follower exposed. Also related: https://github.com/WebAudio/web-audio-api/issues/13.

[joeberkovitz]

Would suggest we think about how this can be done without new native nodes for V1.

E.g.: an AudioWorker that outputs time-averaged volume, piped into another AudioWorker that inverts the signal, routed to a GainNode's gain AudioParam.

[cwilso]

If you're writing it as an AudioWorker, you can do whatever you want - you don't need DynamicsCompressor either, as you can build it yourself. But then, the same is true of EVERY node in Web Audio; you don't technically NEED it, since AudioWorker could do it.

WITHOUT using an AudioWorker, there's only so much you can do. I tried this once: cf https://webaudiodemos.appspot.com/input/index.html, "Noise Gate". The problem is that dynamics effects - compression and expansion such as noise gating - need much better control than you can do by just manipulating LP filters to determine envelope following - you can't avoid "pumping" (hysteresis) without better controls. The envelope follower need for dynamics effects isn't just time-averaged volume.

The DynamicsCompressor already has an envelope stage with separate attack and release controls; if that were simply exposed somehow, we could get at what we need for other dynamics control. Noise gating in particular is pretty critical even just for having basic audio recording, but I can't imagine mixing down EDM music without a sidechain. That exposure could be as simple as, well, if we DO expose .connect on AudioParam (issue #367), then connecting "reduction" would enable sidechaining - except the decibel value scale here would make it challenging. You could probably even manipulate it to fake noise gating, though that would be messier by far. If we do NOT enable connect on AudioParam, I don't understand why reduction is an AudioParam, since it's an output value, not an input.

In short, I think DynamicsCompressor's design is very limited, and it should not have gone into the spec the way it is.

[joeberkovitz]

See my comment on #367 -- can we simply expose the envelope as an alternate, second output of DynamicsCompressorNode? That way it can be wired to anything one likes using the existing version of connect(), IIRC.

[cwilso]

That's pretty much what I suggested in the initial report: "exposing the reduction as an AudioNode that can be connect()ed to other AudioParams". (It shouldn't be "reduction", exactly - it should be the envelope.)

[padenot]

Resolution:

If a node is connected to the _second_ input of a DynamicsCompressorNode, then it is used as a control signal, that controls the compression amount that is to be applied on the _first_ input.

[nothingmuch]

Why not just allow node.connect(AudioParam) arbitrarily? There are many other useful applications apart from compression

[hoch]

@nothingmuch Can you provide some examples? How can you use your idea for sidechain compression?

[nothingmuch]

what I meant was that side chaining as a general purpose concept (treating a signal as a parameter) is useful for broader applications than just side chain compression.

the reason I found this discussion was that i was looking for a way to compute the product of n signals and I was googling "web audio side chain". the binary case for my problem would hypothetically be solved by sig1.connect(gainNode); sig2.connect(gainNode.gain).

admittedly this is a bit off topic for compression but worth a consideration given the proposed changes to DynamicCompressorNode. (apparently side chaining is a narrower term than I thought before I posted _blush_)

[cwilso]

Umm, you already CAN connect from a node to an AudioParam -
http://webaudio.github.io/web-audio-api/#widl-AudioNode-connect-void-AudioParam-destination-unsigned-long-output.
In fact, I used this heavily to fake up an envelope follower from native
nodes in https://webaudiodemos.appspot.com/input/index.html (the "envelope
follower", or to hear it in action, the "wah" effect).

Sidechain input is really just a way to enable easily using the
compressor's envelope (attack and release controls) and its ratio/knee
controls.

On Thu, Dec 11, 2014 at 9:41 AM, Yuval Kogman [email protected]
wrote:

what I meant was that side chaining as a general purpose concept (treating
a signal as a parameter) is useful for broader applications than just side
chain compression.

the reason I found this discussion was that i was looking for a way to
compute the product of n signals and I was googling "web audio side chain".
the binary case for my problem would be solved by sig1.connect(gainNode);
sig2.connect(gainNode.gain).

admittedly this is a bit off topic for compression but worth a
consideration given the proposed changes to DynamicCompressorNode, I
thought it might worth a thought. (apparently side chaining is a narrower
term than I thought before I posted)

—
Reply to this email directly or view it on GitHub
https://github.com/WebAudio/web-audio-api/issues/246#issuecomment-66657604
.

[nothingmuch]

double blush... sorry for wasting your time!

[rtoy]

In https://github.com/WebAudio/web-audio-api/issues/246#issuecomment-60688160, the resolution seems to be to add a second input to the DynamicsCompressorNode that is the control signal for the compression on the first input signal.

Are we really going to do this? In time for v1 and CR and TPAC 2016? We don't even know how the compressor actually works.

Adding WG review label, too.

[joeberkovitz]

@rtoy yes, I thought the sense of the group was that we needed to work out the algorithm properly before ramifying the DynamicCompressorNode with more features

[cwilso]

Note that "sidechain compression" isn't a separate feature, really - it
just means you can plug a different audio input into the control than the
signal. To put it in analog terms, you're just soldering a jack into a
cable.

Sidechain compression is an incredibly common effect, because it's heavily
used in dance music as well as pretty much any music production (my
Novation Circuit groovebox exposes it as a primary page). Without
sidechaining, you're pretty much relegating the usefulness of
DynamicsCompressor to a limiter inserted right before the destination so
you don't clip.

On Wed, Aug 3, 2016 at 7:20 AM, Joe Berkovitz [email protected]
wrote:

@rtoy https://github.com/rtoy yes, I thought the sense of the group was
that we needed to work out the algorithm properly before ramifying the
DynamicCompressorNode with more features

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/WebAudio/web-audio-api/issues/246#issuecomment-237242471,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAe8eQB_yZ4pCzJ06SbVGkMWPG7TE2mcks5qcKORgaJpZM4BD7qG
.

[rtoy]

I'm not debating the usefulness. I'm just wondering about the timing. We'll be adding another "undefined" thing to an already undefined black box---a box that people have wanted defined for years but no one has actually been motivated to define.

[DonKarlssonSan]

I was really surprised to see that DynamicsCompressorNode does not support side chaining. What is the latest update on this? It's still Open. What is the next step?

[hoch]

@DonKarlssonSan The prerequisite would be writing the section for the compressor itself (which currently do not exist). After that, describing how the side chaining work would not be too hard - WG already has a rough idea on how to implement.

[joeberkovitz]

From F2F meeting: The current compressor design is quite limited and being speced as far as practical for V1 as per #10. We plan to introduce a more transparent and flexible compression/expansion/side-chaining/noise-gating approach in the next rev of this spec.

[mdjp]

Could be added to existing compressot and be backwards compatible.
Add one input and sidechain prop. (TPAC 17)

[mdjp]

Addressed by https://github.com/WebAudio/web-audio-api-v2/issues/12 in V2