Re: The DynamicsCompressorNode reduction value

At one point, I'd asked Chris to consider how to do side-chain compression
(an extremely common feature); it would seem that "reduction" would need to
be an AudioNode in order to do that, or something like that, and then it's
not trivial to grab the value.  Probably can't be combined here, but I
wanted to mention it to be thought through before making a breaking change
here.


On Mon, Apr 22, 2013 at 8:22 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> I think reading this attribute will be a faily nieche usecase that we can
> hopefully make the change, implement it in all three engines supporting Web
> Audio, and evangelize our way through possible breakages.  :-)
>
> Do you want me to go ahead and make the spec change (plus writing a Gecko
> patch at the same time)?
>
> Cheers,
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
> On Mon, Apr 22, 2013 at 3:51 PM, Chris Rogers <crogers@google.com> wrote:
>
>>
>>
>>
>> On Mon, Apr 22, 2013 at 12:45 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>>
>>> The current spec codifies the reduction value for DynamicsCompressorNode
>>> as a read-only AudioParam.  That would not actually prevent content from
>>> writing to that value, you could easily do:
>>>
>>> node.reduction.value = 10;
>>>
>>> Or even worse, scheduling automation events on the reduction argument.
>>> I think this is really confusing, and probably all we need here is a
>>> read-only float argument.  Or am I missing something?
>>>
>>
>> I think that's a fair assessment. It would be a breaking change, but
>> maybe not so severe.
>>
>>
>>>
>>> --
>>> Ehsan
>>> <http://ehsanakhgari.org/>
>>>
>>
>>
>