Re: Missing information in the Web Audio spec

Hi Robert, thanks very much for taking a pass through the spec.  I agree
that I need to update the spec to provide much more detail about the
AudioParam methods setValueAtTime() and so on.  It will take a little bit
of time for me to craft the more detailed text explaining these methods
precisely.  Also, I hope to address your other comments soon.

Chris

On Thu, May 10, 2012 at 3:01 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, May 11, 2012 at 4:38 AM, Raymond Toy <rtoy@google.com> wrote:
>
>> On Wed, May 9, 2012 at 6:19 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> In AudioParam, a lot of the processing model is unclear. I assume that
>>> nominally an AudioParam is a function from time to floats. So, for
>>> example,what does setValueAtTime actually do? Does it set the value for all
>>> times >= 'time'? Does setting the 'value' attribute make the function
>>> constant over all times? And what does it mean to be "relative to the
>>> AudioContext currentTime"? Does that mean passing 0 changes the value at
>>> the current time, or that 'time' and 'context.currentTime' are simply on
>>> the same timeline? If the former, clarify by saying that 0 corresponds to
>>> the context's currentTime.
>>>
>>
>> Heh.  I thought setValueAtTime was the easiest method to understand.  It
>> sets the value of the AudioParam to the specified value at time T, where T
>> is the offset from context.currentTime.  Unless you do something else to
>> it, it stays at this value.
>>
>
> But it's got to change the value over some time interval, not just for
> some instant. So what is that time interval? Until the next scheduled
> change? What exactly is the "next scheduled change", for example if
> setValueAtTime is called for a time that's in the middle of an interval
> defined by a previous setValueCurveAtTime?
>
> Yes, this could probably be added, although I think
>> linearRampToValueAtTime is pretty clear.
>>
>
> It's actually not. What is the time interval over which the linear ramp
> happens? From the "last scheduled change"? Like above, "last scheduled
> change" needs to be defined. For example, does the "last scheduled change"
> consider only changes that are already scheduled when
> linearRampToValueAtTime is called? If not, how and when is "last scheduled
> change" evaluated?
>
>  exponentialRampToValueAtTime is less so because there was some issue
>> raised that you can't start or end with a negative value (because exp(x) is
>> always positive for real x).
>>
>
> What is the exponent? If it's "e" (Euler's number), that needs to be
> stated in the spec.
>
> setValueCurveAtTime seems straighforward, unless you need to describe how
>> the interpolation is done if the number of values doesn't exactly match the
>> duration.
>>
>
> "number of values" and "duration" aren't even the same type, so we can't
> talk about whether they "match". Certainly the exact method of
> interpolating values must be defined. To avoid ambiguity, instead of
> referring to "first order filter" or whatever, the spec should just give a
> mathematical definition and describe the filter in non-normative text.
> (Although honestly I don't know why we're referring to first-order filters
> here when the author's given the parameter values explicitly.)
>
> Rob
> --
> “You have heard that it was said, ‘Love your neighbor and hate your
> enemy.’ But I tell you, love your enemies and pray for those who persecute
> you, that you may be children of your Father in heaven. ... If you love
> those who love you, what reward will you get? Are not even the tax
> collectors doing that? And if you greet only your own people, what are you
> doing more than others?" [Matthew 5:43-47]
>
>