This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Per discussion at Audio WG f2f 2013-03-26: * min/maxValue do not need to be exposed as attributes * "intrinsic value" is unclear. Move current text (4.5.1) higher in the spec and reword. * remove computedValue attribute
Partially addressed in: https://dvcs.w3.org/hg/audio/rev/666831bdd706 Still need to re-word "intrinsic value" part...
Following up on this bug, the prose for the intrinsic value is currently saying that when read, AudioParam.value should return the current instrinsic value based on the current time. This is similar to what the computedValue attribute used to return, and there are some concerns about this (see <http://lists.w3.org/Archives/Public/public-audio/2012OctDec/0623.html> for example.) Chris, are you planning to make AudioParam.value a simple value which can be get/set like any other attribute?
(In reply to comment #2) > Following up on this bug, the prose for the intrinsic value is currently > saying that when read, AudioParam.value should return the current instrinsic > value based on the current time. This is similar to what the computedValue > attribute used to return, and there are some concerns about this (see > <http://lists.w3.org/Archives/Public/public-audio/2012OctDec/0623.html> for > example.) > > Chris, are you planning to make AudioParam.value a simple value which can be > get/set like any other attribute? The .computedValue attribute was removed awhile ago as a publicly available attribute in the spec. There is still a section talking about "computedValued", but only as an implementation detail to describe that this is the final internally computed value that will be used by the DSP algorithm. I now see that I forgot to remove a couple of sentences relating to this - now fixed: https://dvcs.w3.org/hg/audio/rev/4f8714b58ef1
Thanks, I actually missed that part of the prose, but I agree that it should have been removed. :-) My question was about this part of the prose (about the intrinsic value): "When read, the .value attribute always returns the intrinsic value for the current time." This basically has the same problems as the old computedValue property, which is the problem I was talking about in comment 2.
(In reply to comment #4) > Thanks, I actually missed that part of the prose, but I agree that it should > have been removed. :-) > > My question was about this part of the prose (about the intrinsic value): > "When read, the .value attribute always returns the intrinsic value for the > current time." This basically has the same problems as the old > computedValue property, which is the problem I was talking about in comment > 2. It's not quite the same as computedValue, since at a specific time, it's a very straightforward mapping and it's possible to get the exact value based on the "scheduled" events (from setValueAtTime(), linearRampToValueAtTime(), etc.).
(In reply to comment #5) > (In reply to comment #4) > > Thanks, I actually missed that part of the prose, but I agree that it should > > have been removed. :-) > > > > My question was about this part of the prose (about the intrinsic value): > > "When read, the .value attribute always returns the intrinsic value for the > > current time." This basically has the same problems as the old > > computedValue property, which is the problem I was talking about in comment > > 2. > > It's not quite the same as computedValue, since at a specific time, it's a > very straightforward mapping and it's possible to get the exact value based > on the "scheduled" events (from setValueAtTime(), linearRampToValueAtTime(), > etc.). But then we will face the same problems discussed in this message: <http://lists.w3.org/Archives/Public/public-audio/2012OctDec/0623.html>...
Web Audio API issues have been migrated to Github. See https://github.com/WebAudio/web-audio-api/issues
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.