Re: DynamicsCompressorNode.reduction is read-only AudioParam ?

> 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
>>>
>>
>>
>