This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17398 - (AudioNodeAsAudioParam): AudioNode as input to AudioParam underdefined
Summary: (AudioNodeAsAudioParam): AudioNode as input to AudioParam underdefined
Status: CLOSED FIXED
Alias: None
Product: AudioWG
Classification: Unclassified
Component: Web Audio API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: TBD
Assignee: Chris Rogers
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-05 12:18 UTC by Michael[tm] Smith
Modified: 2012-11-15 09:57 UTC (History)
5 users (show)

See Also:


Attachments

Description Michael[tm] Smith 2012-06-05 12:18:45 UTC
Audio-ISSUE-41 (AudioNodeAsAudioParam): AudioNode as input to AudioParam underdefined [Web Audio API]

http://www.w3.org/2011/audio/track/issues/41

Raised by: Philip Jägenstedt
On product: Web Audio API

The output of an AudioNode can be connected with to an AudioParam value using AudioNode.connect(). Does that override scheduled value changes, or is the whole AudioParam interface "dead" in that case? In other words, which value takes priority, or are the mixed? (Similar to issue with multiple ramps.)

What happens if the input has multiple channels, which channel is used or is there implicit mixing?

Does AudioParam.unit affect how the input signal is mapped to a value?
Comment 1 Olivier Thereaux 2012-06-07 08:17:24 UTC
[admin] Assigning items currently being worked on by editor.
Comment 2 Olivier Thereaux 2012-06-07 14:51:46 UTC
Changeset from the editor:

Added detailed text:
https://dvcs.w3.org/hg/audio/rev/1fbfc8e7b350
Comment 3 Marcus Geelnard (Opera) 2012-06-12 09:32:19 UTC
It is not specified what "mix" means. E.g. if there are two AudioNode outputs (A, B) connected to an AudioParam, and the AudioParam has an intrinsic value (C), what is the final value? A+B+C, (A+B+C)/3, ...?
Comment 4 Marcus Geelnard (Opera) 2012-08-08 11:39:16 UTC
I'm still a bit confused. The changes describe how the connect() method works. I think a better way to specify this is in the AudioParam section, with a complete description of how the final parameter value is calculated. This would include:

1) The .value attribute
2) The automation values (scheduled changes)
3) The connected inputs

My current assumption would be something like:

[.value attribute] + [automation curve] + sum(mono(inputs))

Also, the specification needs to define what the default values of each contributing factor are. For instance if no events are scheduled or if no inputs are connected.

Also, what happens if cancelScheduledValues() is called with time = 0 or -Infinity? Will the automation curve return to its default value, keep its current value, or throw an exception?
Comment 5 Chris Rogers 2012-08-16 23:33:22 UTC
(In reply to comment #4)
> I'm still a bit confused. The changes describe how the connect() method works.
> I think a better way to specify this is in the AudioParam section, with a
> complete description of how the final parameter value is calculated. This would
> include:
> 
> 1) The .value attribute
> 2) The automation values (scheduled changes)
> 3) The connected inputs
> 
> My current assumption would be something like:
> 
> [.value attribute] + [automation curve] + sum(mono(inputs))
> 
> Also, the specification needs to define what the default values of each
> contributing factor are. For instance if no events are scheduled or if no
> inputs are connected.
> 
> Also, what happens if cancelScheduledValues() is called with time = 0 or
> -Infinity? Will the automation curve return to its default value, keep its
> current value, or throw an exception?

Much more detail for how AudioParam values are calculated added here:
https://dvcs.w3.org/hg/audio/rev/41db9905149d
Comment 6 Marcus Geelnard (Opera) 2012-08-21 11:03:50 UTC
(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.
Comment 7 Jussi Kalliokoski 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())?

+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.
Comment 8 Chris Rogers 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
Comment 9 Marcus Geelnard (Opera) 2012-10-18 07:07:25 UTC
Looks good now.
Comment 10 Olivier Thereaux 2012-11-15 09:57:56 UTC
(In reply to comment #9)
> Looks good now.

Closing.