<rtoyg_m> Yeah, I hate daylight savings.

<scribe> ScribeNick: joe

AudioWorker catchup is first

padenot: we've merged a proxy model and have had some back/forth w Ray and Hongchan about whether we want to evolve the API (not strictly necessary)

<padenot> https://drafts.css-houdini.org/css-paint-api/

padenot: other use of Worklet planned is for API in CSS and they have slightly diff style from what we have planned
... paint API has global PaintWorklet hanging off window, it can load scripts and can then instantiate equivalents of AudioWorkerNodes
... if we used their style, multiple AudioContexts could be hanled. But I prefer to isolate the Worklet.
... I don't think this change is strictly required

BillHofmann: my take is rather than 2 diff models, let's go with one. Can we test something quickly?

padenot: my concern about a global object w a script loader is about collisions. Usually in CSS paint API you have only one window that is going to be painted.
... but there could be multiple AudioContexts in a page.

joe: how big of an adaptation would it be to support multiple Worklets?

padenot: issue is where scripts are loaded

hongchan: importing script at window level has its own strength. loading scripts globally doesn't necessarily mean that state is shared between Worklets. What is the nature of the conflict you're describing?

padenot: maybe I was wrong reading the text
... if loading is not local to AudioContext then there could be collisions

ian: this is a problem we have globally on the Web with custom elements and things like that. We're just assuming that a library will grab its own prefix like jQuery and others.
... We'll still have the same problem in other areas even if we addressed it here

padenot: that was my only concern between the two models

BillH: I would strongly say we shouldn't have two different styles as long as we can test that the one w're adopting satisfies our use cases

joe: Paul, can you describe what would shift in the usage relative to current spec?

padenot: today, script loading takes place against an AudioContext

<padenot> https://drafts.css-houdini.org/css-paint-api/#dom-window-paintworklet

padenot: in the CSS Paint API style you'd get a global paint Worklet that lets you register a function to a paint operation

joe: and how does script loading differ then?

<iank_> paintWorklet.import('script.js').then(function() {

<iank_> // script loaded in paint worklet ready to use

<iank_> });

padenot: someone should write our audio stuff in two different styles to see how it changes

iank: importing from the Worklet returns a Promise that resolves when the script is available
... the actual registration would take place within the JS file

<iank_> audioWorklet.import('script.js').then(function() {

<iank_> var node = audioCtx.createWorkletNode('foo');

<iank_> });

iank: so script.js would associate some function with the name 'foo'

hongchan: doesn't seem to be a sharing conflict

joe: we had in past talked about shared state like impulse responses that would potentially conflict here
... I'm not saying that's a showstopper for this model
... Paul, would be great to have an example of what script JS for a custom node would now look like

https://drafts.css-houdini.org/css-paint-api/#examples

hongchan: in our case, we actually instantiate a node, rather than just making use of some paint code.
... so collision is not the problem we have with this model

<iank_> / inside script.js

<iank_> registerNode('foo', class {

<iank_> constructor(options) {

<iank_> this.foo = options.foo;

<iank_> }

<iank_> doSomething() {

<iank_> this.foo; // local to this instance of the class.

<iank_> }

<iank_> });

padenot: how would we send different read only slices of arrays to different isntances

iank: you should still be able to do that

<padenot> The issue about sharing data in worklets: https://github.com/w3c/css-houdini-drafts/issues/54, in particular https://github.com/w3c/css-houdini-drafts/issues/54#issuecomment-196421769

iank: you could use a message channel with ArrayBuffers

padenot: two links above relate to this; 2nd link explains how we'd use the lifetime of the global scope as defined by the AudioAPI

iank: this is what we'll also be doing for the layout API
... paint is a bit of a special snowflake because there's only one image painter instance

padenot: I think we have everything we need

joe: padenot, can we have a revised example based on the spec of how this will look
... hongchan will create a revised example based on updated API
... agree w Bill that one style is best
... next agenda item: Highlight anything members wish to be discussed at the F2F

padenot: Ray just opened a new issue about filter, we should discuss
... there is a proposal to revise filter equations to be closed to audio cookbook, allowing us to represent more filters

ack

BillHofmann: Jerry and I have both proposed that we should discuss output device selection at F2F

Jerry: I'm trying to get some feedback internally on the draft which I don't think has changed.

BillHofmann: Is there work we should be doing before this? It might be worth recirculating proposal from before?

Jerry: I'm willing to dig up the draft I sent Mark

joe: please catch up first on what's happening in the mediacapture world post-1.0
... we should probably update our current proposal to track what they are doing

BillH: It's interesting that Netflix sees this as important too

joe: other topics?

BillH: we should get an idea of what are the other blocking items before we take next steps in the Recommendation process

https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22

https://github.com/WebAudio/web-audio-api/issues/348

rtoy: the recommendation is use the category if yo udon't know what you're doing, otherwise request specific latency

joe: what do we need to decide?

rtoy: whether we want to have this dual approach and whether suggested names are appropriate

<rtoyg_m> https://github.com/WebAudio/web-audio-api/issues/348#issuecomment-199450729

joe: give us a specific proposal to approave or not

BillH: it solves the problem but I wonder how we communicate that normally you don't want to specify a number
... we're satisfying a particular use case with the specific latency request but normally it's best to let the UA figure it out

rtoy: I don't know how we do that other than saying in the spec that we strongly recommend using the latency category

BillH: I like the concept that easy things should be easy to do but there may not be a good solution to that

rtoy: I'll put up a PR and people can make comments

BillH: +1

https://github.com/WebAudio/web-audio-api/issues/749

rtoy: to review -- do we really need a new node class if all we added is automation?
... Philip made a good argument to not deprecate, just extend
... no one has to change their existing code. if they want new methods, just use 'em
... Bill had a comment that now there's two ways to set positions, which is not great

joe: but we were going to deprecate setPosition()

hongchan: now we need to think about the interaction between these two approaches.

rtoy: it was proposed that using the value setter is as if you do setValueAtTime(currentTime) couldn't this wor the same way?

joe: we have this problem with other nodes too where one needs to make coordinated changes to multiple attributes

rtoy: let's just deprecate the old ways of setting position, orientation, etc

https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone

https://github.com/WebAudio/web-audio-api/issues/762

<rtoyg_m> https://github.com/WebAudio/web-audio-api/issues/762

rtoy: I think this one is most important; we specify nominal ranges for almost everything except playbackRate and detune

joe: my personal opinion is to make this as unlimited as possible

rtoy: note that negative values still not defined.

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: joe
Inferring Scribes: joe

WARNING: No "Topic:" lines found.

Present: hongchan rtoyg_m jdsmith padenot BillHofmann

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

Found Date: 24 Mar 2016
Guessing minutes URL: http://www.w3.org/2016/03/24-audio-minutes.html
People with action items: 

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


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report