25 Jul
2011
25 Jul
'11
7:45 p.m.
On Mon, 2011-07-25 at 16:03 +0000, Fons Adriaensen wrote:
On Mon, Jul 25, 2011 at 11:43:14AM -0400, David
Robillard wrote:
The only real application here is widgets in a plugin UI. A very basic
and generic solution should be fine (but should be as accurate/useful as
possible, of course). Basically we're shooting for enough information
to make a meter go boink in an informative-enough way.
Sending updates for a given block of audio is an inherent requirement.
*/
typedef struct _LV2_PUI_Peak_RMS_Data {
/**
The start of the measurement period. This is just a
running counter that must not be interpreted as any
sort of global frame position. It should only be
interpreted relative to the starts of other
measurement periods in port_event() calls to the same
plugin instance.
This counter is allowed to overflow, in which case it
should just wrap around.
*/
uint32_t period_start;
/**
The size of the measurement period, in the same units
as period_start.
*/
uint32_t period_size;
/**
The peak value for the measurement period. This
should be the maximal value for abs(sample) over all
the samples in the period.
*/
float peak;
/**
The RMS value for the measurement period. This should
be the root mean square value of the samples in the
period, equivalent to sqrt((pow(sample1, 2) +
pow(sample2, 2) + ... + pow(sampleN, 2)) / N) where N
is period_size.
*/
float rms;
} LV2_PUI_Peak_RMS_Data;
In all cases I know of the RMS value required for metering, dynamics
processing, etc. is *not* the average over a period, nor over any other
rectangular window. It is the result of applying a specific lowpass
filter on the squared samples, which one depends on the application. This means that:
* period_start: can be useful.
* period_size: should be defined as the number of samples processed
since the last event.
I believe the intent here was to tolerate skipped updates, so the update
is for the block [period_start .. period_size]
* The definition of RMS as you provide it should be
dropped.
What should it be replaced with? Or, for the basic use case[1]
mentioned would even just peak be enough? Ardour, IIRC, just uses
peaks, and presumably it's metering is sufficient, so that implies maybe
RMS can just go (I do not know if Lars added it for a specific reason).
If RMS isn't really useful for basic metering, I'd rather just drop it
entirely, since it's expensive. Granted, in this day and age the
expense of measuring whatsoever (i.e. iterating over the buffer)
probably dwarfs whatever math you're doing in the process, but still.
Thanks,
-dr
[1] Plugin/UI authors, feel free to pitch in with any others