See also: IRC log
<trackbot> Date: 13 November 2014
<mdjp> Previous meeting minutes -> http://www.w3.org/2014/10/27-audio-minutes.html
<mdjp> http://www.w3.org/2014/10/28-audio-minutes.html
<mdjp> Scribe: hongchan
mdjp: Web Audio Conference at
IRCAM
... the idea of having more representation from working
group.
<mdjp> http://wac.ircam.fr/
mdjp: cwilso, padenot and me will
be there.
... we're looking through many papers and they are great
examples of user-based outlet.
... it is beneficial for use to provide support for them as we
can.
<joe> https://github.com/WebAudio/web-audio-api/milestones/Needs%20WG%20decision
joe: shall we just walk through this and discuss?
cwilso: https://github.com/WebAudio/web-audio-api/issues/373
…: I don't want to replace the buffer source node we already have.
…: we could add another node can be resued.
joe: this should be v.next.
... move on to next issue.
https://github.com/WebAudio/web-audio-api/issues/371
cwilso: this came up while
domenic want to rebuild audio element on top of web audio
api.
... it is about expanding features of decodingAPI.
... this should be v.next.
joe: don't we need some blanket solution?
cwilso, padenot: blanket solution is not appropriate.
joe: next inter-app audio. https://github.com/WebAudio/web-audio-api/issues/358
cwilso: defer decision - leave it as needs working group decision.
joe: what are we waiting for?
cwilso: we need some guidance from developers and users.
https://github.com/WebAudio/web-audio-api/issues/344
padenot: I like this proposal
cwilso: ok
... I need to rethrough comments but I think we're heading to
the same goal.
... you can say ready for editing
https://github.com/WebAudio/web-audio-api/issues/337
cwilso: this is the big one, should go to v2.
https://github.com/WebAudio/web-audio-api/issues/335
padenot: straight forward to spec and doesn't break a thing.
cwilso: this is not possible with promise because it's repeating
it will change the signature in an unfortunate way
joe: we need to know what the signature is when the callback
<Domenic> in general progress + promises should be something like `getPromise(onProgressCallback).then(onSuccess, onFailure)`
<Domenic> but in this case... not good
<Domenic> streams is a better solution IMO for granular decoding
cwilso: I will follow up with domenic and alex to see what the right pattern for this
joe: I'll leave the review tag on it.
https://github.com/WebAudio/web-audio-api/issues/331
joe: it looks like chris wants to push this
rtoy: works for me
cwilso: I don't think analyzer is good for the process requires precision.
https://github.com/WebAudio/web-audio-api/issues/323
padenot: it doesn't break anything.
cwilso: you mean creating a new
node
... certainly there are some demands for this.
... it is easy to implement but the problem is the stability of
biquad filter
rtoy: i'd be happy to ignore this stability issue. then it's on developer's hand.
joe: what is the current proposal?
padenot: exposed coef as audioparam
rtoy: k-rate
joe: i'll mark this as v.1
https://github.com/WebAudio/web-audio-api/issues/302
joe: this is actually more than
the progress
... changing the content of offline audio context as
progress.
... my point of view - chair hat off - so you don't have create
nodes up front.
cwilso: rendering the hour of audio to get one file is not great.
joe: that's what I think too.
padenot: yeah i might be doable
cwilso: there's is an alignment
issue too.
... it is doable but this is going to be a fairly big
undertaking.
joe: the question we should ask
is - without it how offline context would be useful.
... as developer - offline context needs this to be useful
padenot: I think we can try for v1..
cwilso: yeah
joe: ok let's try. I will put it in the v1 bracket and we'll see.
https://github.com/WebAudio/web-audio-api/issues/301
cwilso: resampling might be done elsewhere not our problem.
joe: this is v.next
https://github.com/WebAudio/web-audio-api/issues/296
cwilso: if you change the
playback rate it is hard to calculate the position.
... we don't have sample accurate hook - so users will be
disappointed anyway.
... it is very good for visual feedback, and also good for
making complex changes to playback rate. will make many things
easier. (i.e. DJ app)
padenot: yeah I agree
joe: this goes to v.1
https://github.com/WebAudio/web-audio-api/issues/264
cwilso: this is about utilizing
multiple audio tracks in media elements.
... adding a new node. not a breaking change. should be in
v.1
joe: we need to have a clear way of determining the 'first' track.
https://github.com/WebAudio/web-audio-api/issues/261
cwilso: this is too late.
padenot: yes, next.
https://github.com/WebAudio/web-audio-api/issues/255
cwilso: I would say this is
appendix for last call. Should keep it in v.1.
... non-normative description of all nodes.
joe: okay I put that it the proposal and we can revisit later.
https://github.com/WebAudio/web-audio-api/issues/248
padenot: this would be useful - will cause big change.
cwilso: I want to do the heavy lifting in the native code rather than the javascript.
cwilso
cwilso: it should be in v.next
<mdjp> trackbot, end meeting
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/is done elsewhere/might be done elsewhere/ Found Scribe: hongchan Inferring ScribeNick: hongchan Default Present: +1.650.214.aaaa, mdjp, padenot, joe, Doug_Schepers, jdsmith, hongchan, rtoyg Present: +1.650.214.aaaa mdjp padenot joe Doug_Schepers jdsmith hongchan rtoyg Found Date: 13 Nov 2014 Guessing minutes URL: http://www.w3.org/2014/11/13-audio-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]