Re: The DynamicsCompressorNode reduction value

On Tue, Apr 23, 2013 at 10:41 AM, Chris Wilson <cwilso@google.com> wrote:

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

The .reduction attribute is just for metering purposes so can't be used as
side-chain.


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

Received on Tuesday, 23 April 2013 19:08:08 UTC