Adding an output threshold event to AudioNode

[Pomax]

It is currently not possible to act on an AudioScheduledSourceNode's output signal based on whether or not it is above or below a certain threshold, without using a ScriptNode and the associated massive slabs of code just to inspect the current output over a tiny window. As such, it would be incredibly useful if AudioScheduledSourceNode came with a threshold property and a thresholdcrossed event, where the crossing event comes with a crossing delta function (the diff between the threshold and the value that crossed it, akin to the delta we get in mouse scrollwheel events).

In order to deal with absolute thresholds, the event could either trigger on both positive and negative transitions (e.g. threshold=0.5 kicking in for signals that cross 0.5 as well as -0.5), with an event property that indicates which of the two crossings occurred.

This would allow for things that currently require ScriptNodes to be written as single lines of code based on the threshold crossing signal.

An example of a script that currently requires a crazy amount of ScriptNode code compared to the two-line alternative if a threshold event is available:

volume = context.createGain();
volume.connect(context.destination);
volume.threshold = 0.9;
volume.addEventListener('thresholdcrossed', evt => ui.toggleSignalClipNotice(evt.delta, evt.sign));
...
someSource.connect(volume);

(and in which, just like a scroll handler, the actual event handler can be written such that if there are too many signals per second, only one per however-much-time gets acted on)

[rtoy]

What's the actual use case for this?

It seems to me that this would be better implemented as a separate node instead of having it as part of an existing node.

[Pomax]

Hmm, but how does the node get the information to the "not webaudio" side of things? As a concrete use case, take the UI for a mixing panel. If the audio signal exceeds 0.95, it's time to start turning a nice green bar into a less happy colour. I can, of course, totally effect this by writing a script node, but that's a hell of a lot of code to write for what someone unfamiliar with Web Audio but very familiar with other Web APIs would expect to be able to use an event for.

[rtoy]

I believe that's exactly what a ScriptProcessorNode and AudioWorklNode are for: taking the audio signal and communicating something to the main thread about the signal. It's a far more general solution that can be used anywhere, not just from an AudioScheduledSourceNode. (Hmm. The subject says AudioScheduledSourceNode, but the sample uses a GainNode.)

Marking this as a feature request because that's what it is.

[Pomax]

Yeah I guess I should have said AudioNode, not AudioScheduledSourceNode.

And yes, this is something you could use a scriptnode for, but at the cost of lots of code and needing to become an expert at something hard, when what you want to do feels like it should be simple. It's a little bit like requesting a canvas2d function for drawing arcs. Sure, you can draw four Bezier curves to get a circle, but everyone who wants to do something quick and creative doesn't want to be forced into having to spend time writing all that code just to do a simple thing. So this feature request is only that: a request to make a specific thing simpler to do.

[rtoy]

Adjusted topic to reflect what is actually being requested, which is a threshold for any node.

[mdjp]

New feature request, moving to v.next.

[svgeesus]

This is the classic comparator with hysteresis issue. A single threshold is insufficient, there needs to be a guard band of hysteresis against noise, otherwise a signal near the threshold will constantly toggle.

[Nitzahon]

hark.js provides a simple to use solution for doing something when the threshold is reached, you can even set the threshold yourself, hope this helps someone.