- From: <bugzilla@jessica.w3.org>
- Date: Sat, 06 Oct 2012 00:56:58 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17398
Chris Rogers <crogers@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #8 from Chris Rogers <crogers@google.com> 2012-10-06 00:56:58 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > Much more detail for how AudioParam values are calculated added here:
> > https://dvcs.w3.org/hg/audio/rev/41db9905149d
>
> Ah, that cleared things up :) One thing that seems non-intuitive though is
> that reading the .value attribute does not produce the value that has been
> written to it. E.g. consider the following code:
>
> myParam.value = 3;
> if (myParam.value != 3) alert("I'm confused");
>
> According to the current scheme, it's entirely possible for the code to enter
> the alert-statement.
>
> Wouldn't it be better if .value always returns the value that has been written
> to it, and then we could add a new method for reading the intrinsic value (e.g.
> getIntrinsicValue())?
>
> BTW, with "current time" I assume you mean the value of
> AudioContext.currentTime when the attribute is read (?). Perhaps this should be
> defined somewhere.
I think we're in better shape now with:
https://dvcs.w3.org/hg/audio/rev/79d44e3f3ced
https://dvcs.w3.org/hg/audio/rev/3bddf0c97e77
I think "current time" should be more clear now that this text has moved, since
very nearby text refers explicitly to AudioContext.currentTime
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Saturday, 6 October 2012 00:56:59 UTC