See also: IRC log
<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/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[End of scribe.perl diagnostic output]