Re: [web-audio-api] (AudioNodeAsAudioParam): AudioNode as input to AudioParam underdefined (#159)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17398#6) by Jussi Kalliokoski on W3C Bugzilla. Tue, 21 Aug 2012 11:12:08 GMT

(In reply to [comment #6](#issuecomment-24244592))
> (In reply to [comment #5](#issuecomment-24244587))
> > 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())?

+1

I wonder if it would also make sense for that method to accept a time argument so that one could anticipate the values. The only use case I can think for knowing the intrinsic value aside from JS nodes (which has a different proposed mechanism for that) is to visualize changes, for example knobs turning or so.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/159#issuecomment-24244597