<trackbot> Date: 22 August 2012

<wistoch> hi, this is James Wei from Intel.

<gmandyam> Hi from Giri Mandyam, Qualcomm Innovation Center (calling from 858 area code)

<shepazu> hi, wistoch

<wistoch> +1.408.765.aaaa is me

Renaming interfaces

http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0621.html

Olivier: lists the three options available if we decide to change an interface name

(see http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0621.html)

Marcus: sounds reasonable

Remaming noteOn/noteOff to start/stop or play/stop

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17344

http://www.w3.org/2012/05/02-audio-minutes.html#item02

Olivier: already discussed in May
... asks chris if he still prefers the "deprecated"

Crogers: yes, agree with start/stop

… Deprecated note can be anywhere

Marcus: what does deprecation mean in such context?
... two versions in the market for some time

… incompatibility

… don't want to end up in a difficult situation

CRogers: would be for a limited, but could be long, time

… maybe a year or two

… would be a time when we want to take names out entirely

… Could have console warning in implementation, for instance

Marcus: sounds reasonable

Doug: does any other implementation expect to support the nodeOn/nodeOff syntax?

Marcus: will probably start with start/stop

… depends on timing of our implementation

Doug: if more than one implementation uses it, people will keep it (forever)

Marcus: gut feeling is that we wouldn't support them

Olivier: would like to push for the old name to be kept only in informational note

… would make sure nobody implements it

Resolved: noteOn/noteOff renamed to start/stop, the old name will be mentioned in informational section in the spec.

Renaming setTargetValueAtTime (and other AudioParam methods)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17334

Marcus: when we read spec the first time, we had difficulty understanding what this method did

… much better now the spec has been updated

… the names by themselves don't feel like they explain clearly enough what they are supposed to do

… there have been similar comments on the list

… Chris has made a great job improving this bit of the spec

… but there are name suggestions which feel much more natural

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17334#c4

Olivier: options would be to change none, 1 method, or all 6

CRogers: I understand that people are sometimes confused

… but I still stand by the names as they are

… may be a little bit verbose

… (especially the atTime bit)

… the problem with setTargetValue is that a lot of people don't understand the concept of exponential approach

Marcus: also stand by original impression

… people use functions don't always read the spec fully

… appreciate that we all come from different angles, names feel more or less natural depending on your perspective

… suggestion of dropping the set for methods which do not set value immediately

… thought Rob Baxter's suggestion was making things easier

CRogers: understand suggestion of removing the "set"

… ramp methods specify the end time, the others specify a start time

Marcus: what gets confusing is whether you set a value or a target

CRogers: in the case of setTargetValueAtTime, the change starts immediately

Marcus: understand

CRogers: looking at the simplified names, one of the things you were worried about is that they were not descriptive enough

… that would be true® of the simplified names

Marcus: how about changing setTargetValue to setTarget ?

… at least it would not have verbose set and Value in the same method name

CRogers: I like that. would be open to change setTargetValueatTime to setTargetatTime

Tony: about the distinction between start and end time

… would it make sense to refer to those instead of a generic "time" parameter name

CRogers: sure, it could be called startTime / endTime

Tony: would help for people using for the first time

CRogers: would seem OK

Olivier: what about removing "atTime"?

http://www.w3.org/TR/webaudio/#AudioParam

CRogers: seems fine

Marcus: about value parameter

… the value attribute is not the one being changed by the setValue method

CRogers: agree it is kind of confusing

… go back to wanting the "atTime" now

Marcus: wouldn't be
... wouldn't object to a better name / definition of the value attribute

… confusion between the fallback and automation value

… so maybe we could rename the value attribute

CRogers: in simple cases, people are not going to use the automation method

… which is why it would make sense to keep the simple value name

… probably 75% of cases

… would like to keep simple name

Marcus: yes, it's a powerful interface

… difficult to get all the functionality in a simple name

CRogers: to expand on that, most cases will just set and read the value attribute

… the methods will be used in a few cases when you want to automate

… even more complicated will be to connect audioparam

Marcus: agree it is powerful interface

… do you think there is a real use case for reading the automation ?

… reading value when there is an automation curve, then you set a value

… spec says that when you read value, it will return either value written to it or automation value

CRogers: but do you want to change the value used for the DSP?

Marcus: no functional change

CRogers: wanted to read value being used

… if you don't, the value is meaningless

Marcus: could this be solved by adding a new method to get intrinsic or final value?

… value attribute kept as it is

Tony: that value assigned can still be affecting what the read out value will be, even if you can't read it

CRogers: if you have an automation curve and set that value, that value is ignored at the moment

… alternative would be to set the value and ignore the automation curve

Marcus: there is another situation where you have a value set, and input from an audioNode, the setting the value would effect it

CRogers: suggest - if you set a value then it will cancel any automation curve, and the value will be set as requested

Marcus: would be the same as calling cancelScheduledValues?

CRogers: yes

Marcus: could live with that

… not sure if there is a use case which would a problem

Crogers: at least this way is consistent

Resolution: setting audioparam value while there is an automation curve will cancel that automation curve and set value immediately
... setTargetValueAtTime becomes setTargetAtTime
... the rest of the methods are a decent enough compromise, keep as is

Tony: also to be recorded, we need a way to read a readonly the final / calculated value in

Resolved: need a method to get a readonly value of the combined value

(TBA - bugzilla issue on that one)

Teleconference schedule

Olivier: would like to poll for preferred rhythm

Marcus: weekly may be too often

… at this hour is kind of fine

… fine with Monthly

… quite productive

Doug: suggest bi-weekly for a bit, to get back to the swing of things

Marcus: sounds reasonable

… can't guarantee I can join every time

Tony: we also get a fair amount through Bugzilla, agree weekly maybe too much

Olivier: OK to try every 2 weeks or so

[any preference of which we should tackle next]

JavascriptAudioNode

Marcus: seems like consensus is to do worker-based processing

… it's a topic by itself

… we need to think about the design of it

Olivier: would like to know what the way forward could be… use cases? metrics? experiments?

CRogers: one thing mentioned was the question of number of inputs/outputs and channels

… JSAudioNode has 1 input/1 output but can have as many channels at the moment

… lots of confusion on these threads

… we should have a way to add inputs and outputs

… I added that to the constructor at first

… but everyone was confused, so I removed it

Marcus: we need to have the option of both changing number of input/output channels AND connectors

… useful for custom matrixing or things like that

… not sure how

… don't think any node can change its number of input/outputs after creation, at the moment

… but they can change number of channels after creation

… correct?

CRogers: true

Marcus: suggest a similar approach for JSnode

… methods for setting number of input/output connectors

… as an optional argument

CRogers: tried to have number of inputs/outputs in constructor and it was confusing

… maybe pass an optional json representation

… we need to look at that more closely

Crogers: concerning main thread and workers

… I do favour jsnodes running in web workers

… but many people have been doing it in the main thread

… a lot of people don't know how to use workers

… in the main threads, it's been proven to work

Marcus: I was of the opinion that we should try and prevent it

… but I do see the use cases to do it in the main thread

… worried that there will be 2 ways of do one thing

… would really like to push users to do it in workers

CRogers: may just be a variation on the constructor

… just a difference in where the js code is executing

… and there will be latency sync issues in either case

… some people seem to be angry about that latency

… I can't think of a way to make it feasibly to have that js execution without latency

Marcus: still think there is no fundamental issue with letting any language

… but doesn't match with way workers function

… there were discussions about using shader languages

<gmandyam> +q

Giri: wondering about the logic of supporting both

… is there a way using a worker would help when you have multiple cores?

… seems like increased complexity

Marcus: everything that runs in the main context can possibly be blocked by anything else working there

… e.g animation frames, UI events, setIntervals, document reflows etc

… would block the DOM

… which means you can get quite long dropouts

… in a worker, you would get much less of an issue, and you do get an option of using multiple cores

Giri: even with multiple cores you are still dependent on implementation

Marcus: yes, depends on hardware, OS and implementation

… but those things will typically not block for a very long time

… because of preemptive scheduling

Tony: way I look at this is, when you are in the main thread, implementation doesn't have a lot of choice to prioritize / optimize

CRogers: reiterates use cases to work in main thread… access to other APIs, access to the DOM

… many hoops to jump through

Marcus: agreed, one limitation of workers is data sharing

… no efficient way of sharing data between workers and main context.

… hope to get improvement in the future, but currently major limitations

Crogers: that's why I strongly suggest we support custom in main thread
... there has also been discussion about using shader language

… work being done by Stephane

Marcus: reminds me of openGL

… for something like that to be successful in audio you'd need objects you can access from your shader

Crogers: ideal would be that the shader have access to the audio data from inputs

… depends on details of syntax of audio shaders

… early work but very interesting

… very promising

… no GC, ability to use in real-time thread

[missed comment by Marcus]

CRogers: one limitation he mentioned is limit of single-threaded code

… convolution really need multiple threads

[ no resolution, but we can keep working on adding inputs and outputs to js node, as well as defining the constructor syntax for worker while experiments with shader language happen]

[Adjourned]

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/lu/ly/
No ScribeNick specified.  Guessing ScribeNick: ot
Inferring Scribes: ot

WARNING: No "Present: ... " found!
Possibly Present: CRogers Doug Doug_Schepers Giri Marcus Microsoft Olivier P17 RWC_Audio SCXML SW_RDFWG S_Track Tony VB_VBWG WAI_PF aaaa aabb aacc active audio automata chris dnt foolip gmandyam https inserted joined mage ot paul___irish shepazu trackbot tross wistoch
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0602.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 22 Aug 2012
Guessing minutes URL: http://www.w3.org/2012/08/22-audio-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.