16:00:41 RRSAgent has joined #audio 16:00:41 logging to http://www.w3.org/2016/03/24-audio-irc 16:00:43 RRSAgent, make logs world 16:00:45 Zakim, this will be 28346 16:00:45 I do not see a conference matching that name scheduled within the next hour, trackbot 16:00:46 Meeting: Audio Working Group Teleconference 16:00:46 Date: 24 March 2016 16:00:46 Yeah, I hate daylight savings. 16:01:07 present+ hongchan 16:01:14 present+ rtoyg_m 16:01:17 present+ jdsmith 16:02:38 kawai has joined #audio 16:03:24 BillHofmann has joined #audio 16:03:53 present+ padenot 16:04:01 present+ BillHofmann 16:05:57 ScribeNick: joe 16:06:15 AudioWorker catchup is first 16:06:42 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) 16:07:05 https://drafts.css-houdini.org/css-paint-api/ 16:07:07 padenot: other use of Worklet planned is for API in CSS and they have slightly diff style from what we have planned 16:08:06 padenot: paint API has global PaintWorklet hanging off window, it can load scripts and can then instantiate equivalents of AudioWorkerNodes 16:08:53 padenot: if we used their style, multiple AudioContexts could be hanled. But I prefer to isolate the Worklet. 16:09:07 padenot: I don't think this change is strictly required 16:09:31 BillHofmann: my take is rather than 2 diff models, let's go with one. Can we test something quickly? 16:09:54 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. 16:10:13 padenot: but there could be multiple AudioContexts in a page. 16:10:53 joe: how big of an adaptation would it be to support multiple Worklets? 16:11:01 shepazu has joined #audio 16:11:02 padenot: issue is where scripts are loaded 16:11:49 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? 16:12:39 padenot: maybe I was wrong reading the text 16:13:18 padenot: if loading is not local to AudioContext then there could be collisions 16:13:29 hongchan has joined #audio 16:13:46 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. 16:14:08 ian: We'll still have the same problem in other areas even if we addressed it here 16:14:18 padenot: that was my only concern between the two models 16:15:12 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 16:16:03 joe: Paul, can you describe what would shift in the usage relative to current spec? 16:16:17 padenot: today, script loading takes place against an AudioContext 16:16:53 https://drafts.css-houdini.org/css-paint-api/#dom-window-paintworklet 16:16:54 padenot: in the CSS Paint API style you'd get a global paint Worklet that lets you register a function to a paint operation 16:17:26 joe: and how does script loading differ then? 16:18:31 paintWorklet.import('script.js').then(function() { 16:18:31 // script loaded in paint worklet ready to use 16:18:31 }); 16:18:48 padenot: someone should write our audio stuff in two different styles to see how it changes 16:19:24 iank: importing from the Worklet returns a Promise that resolves when the script is available 16:19:36 iank: the actual registration would take place within the JS file 16:20:01 audioWorklet.import('script.js').then(function() { 16:20:01 var node = audioCtx.createWorkletNode('foo'); 16:20:01 }); 16:20:40 iank: so script.js would associate some function with the name 'foo' 16:21:20 hongchan: doesn't seem to be a sharing conflict 16:22:06 joe: we had in past talked about shared state like impulse responses that would potentially conflict here 16:22:22 joe: I'm not saying that's a showstopper for this model 16:23:12 joe: Paul, would be great to have an example of what script JS for a custom node would now look like 16:23:19 https://drafts.css-houdini.org/css-paint-api/#examples 16:24:31 hongchan: in our case, we actually instantiate a node, rather than just making use of some paint code. 16:24:51 hongchan: so collision is not the problem we have with this model 16:25:13 / inside script.js 16:25:13 registerNode('foo', class { 16:25:13 constructor(options) { 16:25:13 this.foo = options.foo; 16:25:13 } 16:25:13 doSomething() { 16:25:13 this.foo; // local to this instance of the class. 16:25:13 } 16:25:13 }); 16:25:26 padenot: how would we send different read only slices of arrays to different isntances 16:25:32 iank: you should still be able to do that 16:25:53 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 16:26:01 iank: you could use a message channel with ArrayBuffers 16:26:27 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 16:26:59 iank: this is what we'll also be doing for the layout API 16:27:21 iank: paint is a bit of a special snowflake because there's only one image painter instance 16:27:32 padenot: I think we have everything we need 16:28:05 joe: padenot, can we have a revised example based on the spec of how this will look 16:29:03 joe: hongchan will create a revised example based on updated API 16:29:46 joe: agree w Bill that one style is best 16:30:08 joe: next agenda item: Highlight anything members wish to be discussed at the F2F 16:30:17 q+ Bill 16:30:26 padenot: Ray just opened a new issue about filter, we should discuss 16:30:46 padenot: there is a proposal to revise filter equations to be closed to audio cookbook, allowing us to represent more filters 16:31:17 ack 16:31:37 BillHofmann: Jerry and I have both proposed that we should discuss output device selection at F2F 16:32:14 Jerry: I'm trying to get some feedback internally on the draft which I don't think has changed. 16:32:38 BillHofmann: Is there work we should be doing before this? It might be worth recirculating proposal from before? 16:32:52 Jerry: I'm willing to dig up the draft I sent Mark 16:33:39 joe: please catch up first on what's happening in the mediacapture world post-1.0 16:34:37 joe: we should probably update our current proposal to track what they are doing 16:35:07 BillH: It's interesting that Netflix sees this as important too 16:35:34 joe: other topics? 16:35:57 BillH: we should get an idea of what are the other blocking items before we take next steps in the Recommendation process 16:36:19 https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22 16:37:01 https://github.com/WebAudio/web-audio-api/issues/348 16:38:51 rtoy: the recommendation is use the category if yo udon't know what you're doing, otherwise request specific latency 16:39:09 joe: what do we need to decide? 16:39:22 rtoy: whether we want to have this dual approach and whether suggested names are appropriate 16:39:50 https://github.com/WebAudio/web-audio-api/issues/348#issuecomment-199450729 16:39:53 joe: give us a specific proposal to approave or not 16:43:57 BillH: it solves the problem but I wonder how we communicate that normally you don't want to specify a number 16:44:21 BillH: we're satisfying a particular use case with the specific latency request but normally it's best to let the UA figure it out 16:44:46 rtoy: I don't know how we do that other than saying in the spec that we strongly recommend using the latency category 16:45:20 BillH: I like the concept that easy things should be easy to do but there may not be a good solution to that 16:45:29 rtoy: I'll put up a PR and people can make comments 16:45:34 BillH: +1 16:46:02 https://github.com/WebAudio/web-audio-api/issues/749 16:46:58 rtoy: to review -- do we really need a new node class if all we added is automation? 16:47:09 rtoyg_m_ has joined #audio 16:47:12 rtoy: Philip made a good argument to not deprecate, just extend 16:47:25 rtoy: no one has to change their existing code. if they want new methods, just use 'em 16:47:44 rtoy: Bill had a comment that now there's two ways to set positions, which is not great 16:47:58 joe: but we were going to deprecate setPosition() 16:48:50 hongchan: now we need to think about the interaction between these two approaches. 16:49:29 rtoy: it was proposed that using the value setter is as if you do setValueAtTime(currentTime) couldn't this wor the same way? 16:51:31 joe: we have this problem with other nodes too where one needs to make coordinated changes to multiple attributes 16:51:46 rtoy: let's just deprecate the old ways of setting position, orientation, etc 16:54:06 https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone 16:55:53 https://github.com/WebAudio/web-audio-api/issues/762 16:55:54 https://github.com/WebAudio/web-audio-api/issues/762 16:56:14 rtoy: I think this one is most important; we specify nominal ranges for almost everything except playbackRate and detune 16:59:33 joe: my personal opinion is to make this as unlimited as possible 16:59:39 rtoy: note that negative values still not defined. 17:00:42 rrsagent, make minutes 17:00:42 I have made the request to generate http://www.w3.org/2016/03/24-audio-minutes.html joe 17:06:01 oh....damn 17:06:42 mdjp: this time of the year again :-) 17:06:45 apologies joe clock changes have caught me out. 17:07:10 padenot yes, the year is going too quickly! 17:13:02 shepazu has joined #audio 17:20:09 hongchan has joined #audio 17:23:42 hongchan has joined #audio 17:33:58 shepazu has joined #audio 17:49:06 hongchan has joined #audio 17:54:33 shepazu has joined #audio 17:57:34 shepazu has joined #audio 18:43:01 shepazu has joined #audio