Re: DynamicsCompressorNode.reduction is read-only AudioParam ?

Well, ScriptProcessor is kinda heavyweight - if you're just looking for
general feedback (i.e. not precise "OMG clipping happened!"), you don't
need to process EVERY sample; you'd be more efficient by sampling using an
AnalyserNode's getByteTimeDomainData() giving you less data you have to
process in response to a requestAnimationFrame, which is likely how you're
showing the data.  Of course, if you're really doing a fancy monitor, you'd
want RMS as well as instantaneous clip indicators, etc., and yeah, you'd
need a ScriptProcessor.


On Wed, Aug 28, 2013 at 12:46 PM, s p <sebpiq@gmail.com> wrote:

> > it's relatively non-obvious how to show a meter of reduction
>
> It is equally non-obvious to show a level-meter for example. But rather
> easy in fact with a ScriptProcessorNode, ... I would say it is even less
> obvious how to use a read-only monitor value as the input for a param or
> node.
> From a dsp perspective, I certainly prefer having a control signal as
> output, that I can plug-in to another node.
>
> As there is no good solution, probably the one that is the most consistent
> with the spec is the nicest! I cannot think of a place where a "dsp"
> read-only value is provided (except in AudioParam) ... but I cannot think
> of a node that outputs a control signal either.
>
>
> 2013/8/28 Chris Wilson <cwilso@google.com>
>
>> On Wed, Aug 28, 2013 at 12:20 PM, s p <sebpiq@gmail.com> wrote:
>>
>>> > We would still make the reduction a read only float, because it would
>>> really be a monitoring value.
>>>
>>> If you want to make an envelope follower, an output would probably be
>>> more useful, as you could plug-it directly to a gain for example.
>>>
>>
>>  Although that's true, one problem is that it's relatively non-obvious
>> how to show a meter of reduction (or overall volume, for that matter).  The
>> reduction output as a read only floating-point value is valuable for that
>> purpose.
>>
>
>