W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17398] (AudioNodeAsAudioParam): AudioNode as input to AudioParam underdefined

From: <bugzilla@jessica.w3.org>
Date: Tue, 21 Aug 2012 11:12:08 +0000
Message-Id: <E1T3mNU-0000v6-Ur@jessica.w3.org>
To: public-audio@w3.org

Jussi Kalliokoski <jussi.kalliokoski@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |jussi.kalliokoski@gmail.com

--- Comment #7 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-08-21 11:12:08 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())?


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.

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 Tuesday, 21 August 2012 11:12:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC