Re: Two general reasons why AudioParam.value setter cannot be changed to a setTargetAtTime alias

On Wed, 15 Jan 2014 09:21:47 +0000, Olivier Thereaux wrote:

> At this point I am considering this a “bug report” on the
> generic rule which the group has agreed upon. Making an
> exception to that rule for gain might be one way forward.

Thank you for taking the time to consider, reply, and add this
to the call agenda.

An exception for GainNode is not the solution here because the
same problems apply to all AudioParams.  .gain was just an example.

Further, GainNode is the only node requiring de-zippering where a
0th order continuous change in the parameter is sufficient to
provide the necessary de-zippering.  (DelayNode also requires
de-zippering, but a similar continuous change in the parameter is
not effective.)  The reason given for extending the same kind of
smoothing from GainNode to all AudioParams was "consistency".  It
would make no sense to use GainNode as the reason for such as
change to all AudioParams and then make the GainNode behave
differently.

> Would you mind adding it (including the two examples) as an issue in GitHub?
> https://github.com/WebAudio/web-audio-api/issues

There is no bug in the current spec.

The group may have decided that the idea of making the .value
setter an alias for setTargetAtTime() sounded good.  This is what
often happens in a finite-time meeting when there is a proposal
and others are asked to make a decision on whether to pursue the
proposal without having the time to investigate its full
implications.

The proposal is not complete.  Before the proposal can be put into
practice the parameters of setTargetAtTime, for example, need to
be determined and specified.  When the proposal is investigated
further to determine such details, the proposal will need to be
tuned or abandoned.  I expect abandoning the proposal will be the
sensible decision.

The spec at least will not be changed until the proposal is
complete, preferably with a tested implementation.

I would like to come back to the motivation for this.  The only
reasons I've noticed given are that Blink and Webkit do it this
way, consistency, and clarity.  I assume there are no other
reasons for the proposed change?  I don't mean to imply that those
would necessarily be good enough reasons, but Blink and Webkit
don't even do it this way, they don't do it consistently, and
things are not looking clearer to me.

The thread seemed to start by presenting a Webkit/Blink bug in
their interpretation of the OscillatorNode frequency parameter.
The proposal would extend this bug to all parameters for the sake
of consistency.

Received on Monday, 20 January 2014 08:20:09 UTC