Re: Making a VU meter

I just wrote a peak meter and did it with a ScriptProcessor, following the
example set by Chris Wilson at https://github.com/cwilso/volume-meter/ (he
implements an RMS meter much the way you describe - although you have a
nice trick for squaring the waveform, I'm going to remember that!).

It seems to me some kind of envelope extractor node would be useful for
this - a node that extracts the dynamic of the waveform with a variable
window from 1 sample to thousands. There must be one hidden inside the
compressor already to control the compressor level.




On 13 August 2014 02:02, Alan deLespinasse <adelespinasse@gmail.com> wrote:

> I'm asking this, not to find out if there's a better way, but to stimulate
> discussion of new API features that would make it easier and more
> efficient. (Though if you know of a better way under the current spec, I'd
> be glad to hear it.)
>
> In my case, I'm interested in implementing an on-screen VU meter that
> "looks right" to an average user. It doesn't need to be mathematically
> correct in any way.
>
> The most obvious way is to use a ScriptProcessorNode to compute a
> sum-of-squares of each successive buffer, and scale the result
> appropriately. Optional improvements would be to apply a filter first
> (remove DC, give more weight to the more audible frequencies) and to apply
> a window function to each buffer.
>
> I don't want to do that because of the inefficiency of
> ScriptProcessorNode. So here's what I'm doing instead:
>
> I square the signal by feeding it to a gain node and also to the gain
> node's gain parameter. Then I lowpass filter it with a biquad filter. Then
> I use a ScriptProcessorNode to grab just one sample from it each time I
> need a value. (Maybe using an AnalyserNode to get time domain data would be
> better, though I think how that works may be underspecified.)
>
> Obviously it's not optimal, but it seems to work pretty well. I probably
> should filter the signal a bit first, but I haven't bothered.
>
> A slightly different problem would be if you wanted a real peak-to-peak
> meter, so the user would know how close the signal was to clipping. I think
> the only way to do that currently would be to do it all in a
> ScriptProcessorNode.
>
> I expect both will be needed pretty frequently in web audio apps. So
> should there be a special feature for this? Or more general-purpose
> features that make them easier to implement? Or am I missing an
> already-existing way?
>
> One general-purpose feature that would make it relatively easy would be if
> Float32Array had vector operations like "sum of squares" and "find
> maximum/minimum value". I'm sort of surprised that it doesn't.
>



-- 

Cheers,
Stephen


<http://cruncher.ch>
               *web*: cruncher.ch
               *twitter*: @cruncher <http://twitter.com/cruncher>
               *phone*: +41 76 547 30 32
               *email*: stephband@cruncher.ch

Received on Wednesday, 13 August 2014 00:33:53 UTC