Re: Clarification of the AudioParam time/values in the spec

On Mon, Feb 4, 2013 at 9:50 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote:

> On Mon, Feb 4, 2013 at 8:27 PM, Chris Rogers <crogers@google.com> wrote:
>
>>
>>
>> On Mon, Feb 4, 2013 at 9:39 AM, Ehsan Akhgari <ehsan@mozilla.com> wrote:
>>
>>> The AudioParam definition in the spec relies on notions such as the
>>> previous time and previous value.  So far I have assumed that when the spec
>>> is talking about the previous time or the previous value, it's talking
>>> about the time and value parameters of the previous event in the timeline.
>>> Is that true?
>>>
>>> It would be very helpful for somebody to clarify this section of the
>>> spec.
>>>
>>
>> Yes, that's the idea.  I just did a quick search for "previous" in the
>> spec and see that's the meaning in nearly all cases.  If there's something
>> specific I can clarify, I'll do my best to help out.
>>
>
> I think what is confusing is that the previous value might be taken as the
> computed value of the previous tick or something...  But I'm not really
> sure how you could clarify it.  One idea is to explicitly define what the
> time and value of each type of automation event is.  Do you think that
> would make sense?
>

Right now I have some text that reads:
"
An AudioParam maintains a time-ordered event list which is initially empty.
The times are in the time coordinate system of AudioContext.currentTime.
The events define a mapping from time to value. The following methods can
change the event list by adding a new event into the list of a type
specific to the method. Each event has a time associated with it, and the
events will always be kept in time-order in the list. These methods will be
called automation methods:
"

Is there some way I can be more clear?  I think the idea that each event
has a time is clear.  The value specific to each event is described in the
section for the methods corresponding to each event.



>
> Also, there is an edge case which I think the spec doesn't mention: what
> needs to happen when there is no previous event?  In the Gecko
> implementation I have just assumed that we should take the default value
> where that's needed.
>

Yes, I think that seems reasonable.  It's really a mis-use of the API to
not at least call setValueAtTime() to establish a start point.  But, of
course you're right that we need to do something if somebody misuses the
API.  I can update the spec if you're happy with that.


>
> Cheers,
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
>