Re: AudioBufferSourceNode.gain

On Fri, May 31, 2013 at 1:20 PM, Kevin Gadd <kevin.gadd@gmail.com> wrote:

> If gain is already used frequently enough to be impossible to change, does
> this mean everything previously released in Chrome builds re: web audio
> can't be changed because apps might use it? Weren't noteGrainOn and
> noteGrainOff changed, or are the old names required to be supported forever
> for this same reason?
>

The .gain attribute was removed from the spec a long time ago, but a few
developers have continued to use it such as PlayCanvas.  Given that they've
already updated their most recent library, we'll just have to track down a
couple other similar developers and then can possibly phase out support in
WebKit and/or Blink.

Something like noteOn() versus start() is a lot more problematic, because
nearly all developers have been using noteOn(), and shipping versions of
iOS and Safari don't yet support start(), so developers have been very
hesitant to uniformly switch to start().


>
> Arguably if they were using prefixed AudioContext, you should be OK with
> removing a feature that has an existing analog that devs can switch to.
> Maybe mark it as deprecated first and work with developers to get their
> code out in the wild switched over to using a proper GainNode. If it wasn't
> in the spec, they shouldn't have been using it in the first place, no?
>

The problem is that many developers check for the existence of
AudioContext, use that if found, and then fallback to webkitAudioContext,
etc.  Deprecation paths are  something we can certainly work with in some
cases.


>
>
> -kg
>
>
> On Fri, May 31, 2013 at 3:55 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>> Den 2013-05- 11:22:34 skrev Olivier Thereaux <Olivier.Thereaux@bbc.co.uk
>> >:
>>
>>
>>  Hi Chris, all
>>>
>>> On 09/05/2013 19:24, "Chris Rogers" <crogers@google.com> wrote:
>>>
>>>> Unfortunately there's enough content out there using it that I cannot
>>>> recommend removing it from WebKit/Blink.
>>>>
>>>
>>> Is the information about how many sites/apps using a given feature
>>> public,
>>> or could it be made public? I am curious about the raw numbers - the
>>> notion that a feature is used "a lot" is very vague and makes me slightly
>>> ill at ease.
>>>
>>>
>>>  One notable one is http://playcanvas.com/ which is a game library.
>>>>
>>>
>>> It looks like Playcanvas is in trial mode at the moment, which would
>>> suggest that it doesn't yet have a massive user base.
>>>
>>
>> Even if there's a massive user base, I would expect site/app authors to
>> constantly update the engine to the latest version, especially when the
>> engine is built on non-final APIs. That's the way the Web works -
>> deployment is cheap.
>>
>> For example, I've written stuff for WebGL a year ago that does not run
>> well in browsers anymore (my guess is changes in GLSL translations) - if
>> that was a public site (or at least something that was generating traffic
>> or even revenue), I would have updated my code to reflect the changes in
>> the latest versions of the browsers.
>>
>> /Marcus
>>
>>
>>
>>  There may be room to
>>> manoeuvre. We should probably try getting a line of communication with
>>> them and discuss the possibility that some features are still a moving
>>> target. For all we know they may be perfectly comfortable removing
>>> features if our group decides not to standardise them.
>>>
>>> I will reach out to them and see what happens.
>>>
>>> Olivier
>>>
>>>
>>>
>>> -----------------------------
>>> http://www.bbc.co.uk
>>> This e-mail (and any attachments) is confidential and
>>> may contain personal views which are not the views of the BBC unless
>>> specifically stated.
>>> If you have received it in
>>> error, please delete it from your system.
>>> Do not use, copy or disclose the
>>> information in any way nor act in reliance on it and notify the sender
>>> immediately.
>>> Please note that the BBC monitors e-mails
>>> sent or received.
>>> Further communication will signify your consent to
>>> this.
>>> -----------------------------
>>>
>>
>>
>> --
>> Marcus Geelnard
>> Technical Lead, Mobile Infrastructure
>> Opera Software
>>
>>
>