Re: DynamicsCompressorNode.reduction is read-only AudioParam ?

> The downside of this is you can't effectively use the compressor as an
envelope follower.

Well ... then 2 inputs, 2 outputs!!!

> the compressor does not explicitly state, but I believe it should be
stereo-linked

What about if you have a mono signal?


2013/8/28 Chris Wilson <cwilso@google.com>

> Or we could do it that way, yes - have a second Control input, and if it's
> not connected, the control signal is taken from the input.
>
> The downside of this is you can't effectively use the compressor as an
> envelope follower.  It's possible to do this in other ways, of course
> (LP-filtered rectified signal, e.g.), but not with the attack/release
> controls.  If we exposed the amount of reduction as an audio node output;
> then you can route it however you like, including driving a Gain on another
> signal.
>
> Actually, this brings up an excellent point; the compressor does not
> explicitly state, but I believe it should be stereo-linked (reduction is
> applied uniformly on both channels, based on both inputs, to prevent stereo
> image shifting).
>
>
> On Wed, Aug 28, 2013 at 10:30 AM, s p <sebpiq@gmail.com> wrote:
>
>> > I do think we must design sidechain compression into the
>> DynamicCompressor
>>
>> So why not having a second input?
>>
>>
>> 2013/8/28 Chris Wilson <cwilso@google.com>
>>
>>> Incidentally, I believe the reason is related to side-chain compression;
>>> I'd had a conversation with Chris about this a while ago, and his take was
>>> that sidechain compression could be done by assigning the .value of a
>>> gainNode.gain to the AudioParam output of reduction.  This does not work
>>> (IIRC) in Blink/webkit, and AFAIK, nowhere else do you assign
>>> audioparam.value to an audioparam and expect it to make a connect()ion-like
>>> connection.
>>>
>>> I do think we must design sidechain compression into the
>>> DynamicCompressor before we finish off v1, so I'd like to consider that
>>> together with this change.  Sidechain (ducking, de-essing, etc) is
>>> incredibly common.
>>>
>>>
>>> On Wed, Aug 28, 2013 at 9:29 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>>>
>>>> This has been discussed in <
>>>> http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0181.html>,
>>>> and we agreed that it should be a readonly float.  Paul, can you please
>>>> make that change, if nobody objects?  I'd like us to fix Gecko based on
>>>> that as soon as possible if we change the spec here.
>>>>
>>>> --
>>>> Ehsan
>>>> <http://ehsanakhgari.org/>
>>>>
>>>>
>>>> On Tue, Aug 27, 2013 at 10:30 AM, s p <sebpiq@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> DynamicsCompressorNode.reduction is specified to be a monitor value,
>>>>> so read-only, but the interface says it's an AudioParam (
>>>>> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#DynamicsCompressorNode-section).
>>>>> So my question is what is the point in having a read-only AudioParam?
>>>>>
>>>>> Sebastien Piquemal
>>>>>
>>>>
>>>>
>>>
>>
>