IRC log of audio on 2017-06-20

Timestamps are in UTC.

13:08:02 [RRSAgent]
RRSAgent has joined #audio
13:08:02 [RRSAgent]
logging to http://www.w3.org/2017/06/20-audio-irc
13:15:07 [ChrisL]
rrsagent, make logs public
13:15:28 [Zakim]
Zakim has joined #audio
13:15:50 [ChrisL]
zakim, remind us in 8 hours to stop
13:15:50 [Zakim]
ok, ChrisL
13:16:05 [ChrisL]
scribenick: ChrisL
13:16:09 [ChrisL]
chair: Matt
13:16:45 [ChrisL]
Agenda: https://www.w3.org/2011/audio/wiki/F2F_June_2017
13:17:50 [ChrisL]
Present: Hongchan, Ray, Paul, ChrisW, Joe, Matt, ChrisL
13:18:42 [ChrisL]
ChrisW: would like to have a bit of "structure for v.next" discussion wrt incubation
13:18:59 [ChrisL]
mdjp: can discuss over lunch
13:19:23 [ChrisL]
Topic: Issue resolution all V1 blockers
13:20:34 [joe]
joe has joined #audio
13:21:03 [joe]
https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22V1+Blocker%22+sort%3Acreated-asc
13:21:13 [hoch]
hoch has joined #audio
13:21:40 [joe]
https://github.com/WebAudio/web-audio-api/issues/10
13:21:45 [rtoyg]
rtoyg has joined #audio
13:21:51 [ChrisL]
(we discover that MIT Guest blocks IRC, sigh)
13:22:11 [mdjp_]
mdjp_ has joined #audio
13:22:51 [ChrisL]
padenot: Wrote some text, see link
13:22:56 [padenot]
https://rawgit.com/padenot/web-audio-api/10-dynamicscompressor/index.html
13:23:12 [padenot]
https://rawgit.com/padenot/web-audio-api/10-dynamicscompressor/index.html#processing
13:23:55 [ChrisL]
padenot: describing chrome compressor, it is before the blink fork
13:24:31 [ChrisL]
... intent to spec something that is not fully precise but covers general algorithm with some leeway for the exact shape of the soft knee
13:24:48 [ChrisL]
... should not be widely different
13:24:58 [ChrisL]
... the end blocks also can differ
13:25:24 [ChrisL]
... missing computation of native gain
13:25:50 [ChrisL]
... inner loops needs to be finished. rest should be correct
13:26:06 [ChrisL]
... it is quite complex, reverse engineering the curves
13:26:16 [ChrisL]
... lots of magic numbers
13:27:19 [ChrisL]
joe: we had a call talking about the best way to do this. Hard to reverse engineer. To what extent do we wantto frame it as an algorithm rather than one instance of a compressor that complies with the spec?
13:27:30 [ChrisL]
... could be a danger in miring in details
13:27:58 [ChrisL]
padenot: current depth is enough. Unambiguous - peak detecting not RMS for example
13:28:18 [ChrisL]
... mostly audio rate inside
13:28:41 [ChrisL]
... most sub algorithms are sets of constraints
13:29:08 [ChrisL]
... rather than a polynomial expression for example
13:29:34 [ChrisL]
https://rawgit.com/padenot/web-audio-api/10-dynamicscompressor/index.html#processing
13:29:50 [ChrisL]
padenot: after my todos we can look it over
13:30:24 [ChrisL]
padenot: should be possible to implement without reading the code
13:30:52 [ChrisL]
joe: recognise this is copping out to some extent, talking about making another pass on compression for v2
13:31:32 [ChrisL]
joe: someone can build a similar compressor. Testable conformance
13:31:45 [ChrisL]
padenot: possible to write some knee tests that pass
13:32:04 [ChrisL]
... knee, curve continuity, peak vs rms is specced
13:32:44 [ChrisL]
joe: attack and release time constants calculated in a convoluted way with state in serral vars, hard to follow
13:33:01 [joe]
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/audio/DynamicsCompressorKernel.cpp
13:33:02 [ChrisL]
s/serral/several
13:33:14 [hoch]
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/audio/DynamicsCompressorKernel.cpp?l=260
13:33:31 [ChrisL]
cwilso: concerned on testability, not truly interoperable
13:34:14 [ChrisL]
padenot: goal of compressor is to make things not move too much in terms of volume. so impls that do a similar job can be tested
13:34:39 [ChrisL]
joe: valid criticism
13:35:39 [ChrisL]
padenot: curve must be continuous (so it doesn't introduce harmonics)
13:36:26 [ChrisL]
... adaptive release and attack, and precise knee shape, are the points of flexibility
13:36:42 [ChrisL]
cwilso: maybe punt on this for v1, if it is not interoperable
13:37:13 [ChrisL]
... like the acid test in IE
13:37:51 [ChrisL]
... iterative approach to conformance
13:38:30 [ChrisL]
ChrisL: are you suggesting dropping compressor from v1
13:38:58 [ChrisL]
cwilso: yes, incubate as a separate thing, impls can look at it but its outside the spec for now
13:39:54 [ChrisL]
cwilso: most ppl don't care on the details, just using it to stop sudden jumps or overload output
13:40:54 [ChrisL]
padenot: there are other examples of loose algorithms, like boxblur is not necessarily gaussian blur
13:41:34 [ChrisL]
joe, chris: antialiasing another example
13:42:31 [ChrisL]
joe: want a loose spec that chris rodgers algo is a conforming impl of. Lets us add that node in the spec.
13:43:10 [ChrisL]
ChrisL: will we want to add a different, more configurable compressor as well in v2
13:43:21 [ChrisL]
hoch: it has no sidechain
13:43:38 [ChrisL]
padenot: it is a bus compressor not a channel strip compressor, effectively
13:44:29 [ChrisL]
ChrisL: can test with an analyser node, loud sine, check for harmonics
13:44:48 [ChrisL]
padenot: yes, did some tests like that last week
13:45:09 [ChrisL]
cwilso: saw a typo and also the knee and the threashold, don't understand the knee param
13:46:14 [ChrisL]
cwilso: threashold should be to the left where the soft and hard knees diverge
13:46:43 [ChrisL]
joe: we should walk through and get input to work with
13:46:52 [ChrisL]
cwilso: knee is additive right?
13:47:11 [ChrisL]
joe: lets decide first if we are going to punt
13:47:19 [ChrisL]
padenot: feels like cheating to me
13:47:56 [ChrisL]
joe: css has stuff like this all the time
13:48:48 [ChrisL]
... drop from the spec, impls can have one, but spec does not describe it
13:48:56 [ChrisL]
... new impls will not have one
13:49:54 [ChrisL]
cwilso: no longer convinced current behaviour is desirable. sad it is interoperable. Changing impls to match spec would change the rendefred rfesult a lot
13:50:05 [ChrisL]
hoch: if we punt, what happens in vnext?
13:52:03 [ChrisL]
ChrisL: make simple testable statements and do a much better one in v2
13:52:43 [ChrisL]
joe: punting gives uncertainty for v2. If we do not mention existing node then it is net=ither in v1 or v2, but if we do then there are two evolving compressors, the legacy and the new
13:53:29 [ChrisL]
joe: sidechaining and expansion are clearly missing
13:54:13 [ChrisL]
cwilso: enough dials make the expander and compressor do averything, but its nothing like what people actually use
13:55:38 [ChrisL]
joe: lets make a description that is internally consistent, testable, and is in line with current behaviour
13:55:54 [ChrisL]
so does not necessarily conform to what people expect from a compressor
13:58:22 [ChrisL]
hoch: so changing knee value affects loudness?
13:58:25 [ChrisL]
padenot: yes
13:58:36 [ChrisL]
cwilso: by knee value divided by ratio
14:01:10 [ChrisL]
(drawings on whiteboard
14:01:22 [ChrisL]
cwilso: diagram in spec currently is wrong
14:01:38 [ChrisL]
... can certainly make it testable
14:02:16 [ChrisL]
joe: it is c1 continuous
14:02:41 [ChrisL]
joe: the polynomial is the release, not the knee
14:03:41 [ChrisL]
hoch: the knee *has* to be centered
14:05:10 [ChrisL]
joe: can we start going through paul's section and decide what we need to change
14:05:40 [ChrisL]
joe: propose we keep the loose descriptive node in the spec
14:05:50 [ChrisL]
(no objections)
14:06:29 [ChrisL]
padenot: I adresssed your initial comments
14:07:54 [ChrisL]
joe: need to define curve as a target output level based on input level
14:08:00 [ChrisL]
... never says that
14:08:17 [ChrisL]
... also needs to say first order continuous
14:08:54 [ChrisL]
... update diagram to have threashold where curves diverge and indicate the knee width
14:09:17 [ChrisL]
joe: internal graph, is that a helpful formalism?
14:09:30 [ChrisL]
rtoyg: doesn't work
14:10:39 [cwilso]
another type: "enveloppe rate"
14:11:28 [ChrisL]
hoch: the gain node is gain computor, the other part needs to be the envelope follower
14:11:42 [ChrisL]
padenot: did not want to respecify the delay
14:11:50 [ChrisL]
... 6ms hardcoded
14:12:36 [ChrisL]
hoch: otherwise it looks lije the compressionprocessor is doing the compression
14:12:48 [ChrisL]
hoch: so it is two render quantum delay
14:13:18 [ChrisL]
joe: now we have detector average and compression gain
14:13:35 [ChrisL]
hoch: attack is one render quantum
14:13:55 [ChrisL]
cwilso: is inventing a temporary class the right way to do this?
14:14:39 [ChrisL]
rtoyg: people are going to try to run the pseudo code and get confused
14:14:56 [ChrisL]
ChrisL: call them blocks not nodes.
14:15:12 [ChrisL]
hoch: knee param bothers me, it has no units
14:15:25 [ChrisL]
padenot: knee is in dB relative to threashold
14:15:50 [ChrisL]
joe: good to do it as a range. it is an increment not an absolute value
14:16:45 [ChrisL]
joe: in step 5 is is product not division
14:16:48 [ChrisL]
padenot: right
14:18:03 [ChrisL]
joe: envelope rate?
14:18:14 [ChrisL]
padenot: is the result of executing the steps
14:18:50 [ChrisL]
... env rate tells you the instantaneous slope of the curve for this sample
14:19:30 [ChrisL]
padenot: slpe between two samples
14:19:56 [ChrisL]
joe: ok, time derivative
14:20:54 [ChrisL]
ChrisL: worried by "It is allowed, for example" make it a complete list
14:21:32 [ChrisL]
padenot: adaptive release is a classic thing to do, also auto release, not sure how that is computed
14:22:42 [ChrisL]
padenot: attacking, you increase compression level; releasing, you get a negative number that subtracts from the compression level
14:22:58 [ChrisL]
... step 6.4 says to add or subtract it
14:23:53 [ChrisL]
joe: envelope rate is not fully spelled out
14:24:19 [ChrisL]
... controls how much compressor rate is changed
14:24:42 [ChrisL]
Add the difference between attenuation and detector average to detector average, and clamp detector average to 1.0.
14:25:21 [ChrisL]
joe: that is a no-op
14:26:02 [ChrisL]
rtoyg: exponentially smoothed
14:26:42 [ChrisL]
padenot: yes it is just smoothed a bit
14:27:23 [ChrisL]
rtoyg: if not releasing, rate is 1
14:27:44 [ChrisL]
joe: just say it is smoothed
14:30:19 [ChrisL]
joe: do we need makeup gain?
14:30:51 [ChrisL]
padenot: it is a term of art and in a lot of products. so result is as loud as before
14:31:35 [ChrisL]
... power shaped based on gain level
14:34:23 [ChrisL]
rtoyg: hard to test as you have only input and output, no access to internals
14:34:34 [ChrisL]
padenot: can sample the reduction parameter
14:35:10 [ChrisL]
joe: can do measurements to see what it converges on. and how it responds to spikes to see the attack and release curves
14:35:50 [ChrisL]
joe: soft knee by checking derivatives are close, before and after the change section
14:36:11 [ChrisL]
padenot: also test the lookahead
14:36:37 [ChrisL]
padenot: can test makeup gain too
14:36:48 [ChrisL]
rtoyg: that is kind of hard
14:36:55 [ChrisL]
padenot: can test if it is applied
14:38:02 [ChrisL]
cwilso: this is what we did with panner, we greatly simplified the first one which was wildly complex
14:38:55 [ChrisL]
cwilso: chris's intent was to replicate a high end compressor with few knobs
14:40:10 [ChrisL]
cwilso: better idea to rip out this complex compressor
14:41:12 [ChrisL]
cwilso: this investigation paul did is super valuable. still have fixed lookahead, configurable attack and release
14:41:44 [ChrisL]
joe: will allow too much leeway to have real interop. lets people build code now
14:43:19 [ChrisL]
joe: so should paul continue and incorporate our feedback
14:43:23 [ChrisL]
padenot: will do
14:43:33 [ChrisL]
rrsagent, here
14:43:33 [RRSAgent]
See http://www.w3.org/2017/06/20-audio-irc#T14-43-33
14:44:48 [ChrisL]
padenot: will work on this from 2 July so expect by 6 July
15:20:50 [joe]
joe has joined #audio
15:27:35 [joe]
https://github.com/WebAudio/web-audio-api/issues/1193
15:27:51 [ChrisL]
Topic: Revise AWN/AWP instantiation algorithm: structured serialization and abstract operation
15:28:20 [joe]
https://cdn.rawgit.com/hoch/web-audio-api/fe176b7d0cb5b1576242277ec6bb3d5d1ac73377/index.html#instantiation-of-AudioWorkletNode-and-AudioWorkletProcessor
15:28:30 [ChrisL]
hoch: original proposal to inst a pair of nodes in blocking way, there is nothing blocking on main thread
15:28:55 [ChrisL]
... now we do it in parallel, constuction calls back to main thread on completion to say it is ready
15:29:27 [ChrisL]
... if constructor has errors we throw so it fails and your worklet node is in an odd state. can be connected still
15:30:36 [ChrisL]
hoch: main difference is step 9, que a control message
15:30:44 [ChrisL]
joe: message channel is also new
15:30:56 [ChrisL]
hoch: main concern is block or not
15:31:14 [ChrisL]
... we don't block and return the reference
15:31:57 [ChrisL]
ChrisL: advantage of blocking?
15:32:09 [ChrisL]
hoch: clear failure and no dangling reference
15:32:30 [ChrisL]
joe: is running event described?
15:33:17 [ChrisL]
hoch: yes I need to explain the "running" event
15:33:29 [ChrisL]
Queue a task the control thread to fire "running" event to the associated AudioWorkletNode.
15:33:52 [ChrisL]
hoch: maybed that is in a different PR
15:34:11 [hoch]
https://cdn.rawgit.com/hoch/web-audio-api/33e214083425af8066381c73122dafe846de6243/index.html#AudioWorkletNode
15:34:57 [ChrisL]
hoch: previously we did not have a state proporty. Now we do as they are async
15:35:26 [ChrisL]
... describes state of associated worklet. Joe said there is an internal flag, active source
15:35:50 [ChrisL]
enum AudioWorkletProcessorState {
15:35:50 [ChrisL]
"pending",
15:35:50 [ChrisL]
"running",
15:35:52 [ChrisL]
"stopped",
15:35:54 [ChrisL]
"error"
15:35:56 [ChrisL]
};
15:36:26 [ChrisL]
padenot: state is exposed through IDL on main thread. activesource is an internal flag, main thread or worklet
15:36:32 [ChrisL]
hoch: rendering thread
15:37:00 [ChrisL]
joe: implicit communication from AWN
15:37:18 [ChrisL]
padenot: sources can finish on the rendering thread
15:37:39 [ChrisL]
... reflect back to main thread
15:38:25 [ChrisL]
joe: active source exists to drive lifetime decisions. if true it is an internal reference, like playing for ABSNs
15:38:38 [ChrisL]
... only object anyone can have a ref to
15:38:51 [ChrisL]
... we don't say how it happens
15:38:59 [ChrisL]
padenot: how we toggle the flag
15:40:00 [ChrisL]
... cross thread communication, is a problem with JS memory model
15:40:11 [ChrisL]
... add sentence to say queue a message
15:40:18 [ChrisL]
joe: think we need a local copy
15:40:35 [ChrisL]
padenot: needs to be a simple task in the main event loop
15:40:43 [ChrisL]
hoch: que the written value
15:41:18 [ChrisL]
joe: rendering thread cop influences if subsequent communications happen.
15:41:30 [ChrisL]
s/cop/copy
15:41:57 [ChrisL]
joe: what is gthe purpose of state. construction status or also the active source or not
15:42:44 [ChrisL]
padenot: need to know if something will run or not, becausde low level atomics. Need to know if it will terminate
15:43:12 [ChrisL]
padenot: we can't rely on the context state
15:43:57 [ChrisL]
joe: do we want a state reflecting construct status plus a separate flag, or one combined flag
15:44:36 [ChrisL]
hoch: we can move active flag into rendering thread
15:45:50 [ChrisL]
joe: spec has ASF. unclear wrt coupling to ASF, satde related to flag. 2 ways to fix. Get rid of asf, and say stte of AWN. Or, have state be pending|error|created and a separate ASF
15:46:13 [ChrisL]
s/satde/state
15:46:36 [ChrisL]
hoch: what is difference from state of running source
15:47:12 [ChrisL]
hoch: my preference is to do that
15:47:26 [ChrisL]
joe: there is handwaving currently
15:47:39 [ChrisL]
padenot: solves this issue
15:48:11 [ChrisL]
joe: if me msg ASF, which copy drives GC
15:48:24 [ChrisL]
padenot: main thread one. GC is on main thread
15:49:14 [ChrisL]
hoch: found a problem when implementing, creating JS on separate machine in this thread, so someone needs to take care of GC
15:49:31 [ChrisL]
padenot: no cross refefrences across worklet boundary
15:49:59 [ChrisL]
hoch: transferable is okay
15:51:11 [ChrisL]
hoch: ok so no need to mention in the spac
15:51:20 [ChrisL]
padenot: well defined in ecma spec
15:51:33 [ChrisL]
s/the spec/our spec/
15:52:27 [ChrisL]
joe (types resolution into the GH issue)
15:52:44 [ChrisL]
joe: stopped does not mean dead
15:53:04 [ChrisL]
hoch: we have allthe states we need?
15:53:07 [ChrisL]
joe: yes
15:53:15 [joe]
https://github.com/WebAudio/web-audio-api/issues/1089
15:53:36 [ChrisL]
Topic: Specify the channels order for `HTMLMediaElement`
15:54:57 [ChrisL]
joe: trouble with a mandated order
15:55:50 [ChrisL]
joe: lack of access to information on canonical channel ordering. Sometimes it is unknown
15:56:02 [ChrisL]
... hoch suggested a channel map
15:56:43 [ChrisL]
padenot: what codec gives this problem
15:56:52 [ChrisL]
hoch: 8 or 16 channel
15:57:20 [ChrisL]
padenot: ogg specifies an order and aac, mp4, wav has wav order
15:57:39 [ChrisL]
... restricting to formats present on the web, which one has this issue
15:58:21 [ChrisL]
padenot: info is lost
15:58:58 [ChrisL]
padenot: in firefox we always remap to smte order else facebook would not be able to do VR
15:59:08 [ChrisL]
s/smte/smpte/
16:00:02 [ChrisL]
padenot: found two public orderings, the windows order and the smpte order (9which is less public)
16:00:48 [ChrisL]
padenot: wanted well known and widely adopted order. these 2 are the same up to a large numbert of channels. but also want discrete , used for 360 audio
16:01:09 [ChrisL]
... channels separate from speakers
16:01:34 [ChrisL]
... chrome, ff and safarfi all implemented non mapped channels
16:03:54 [ChrisL]
padenot: jerry asked what happens if we lose the ordering info
16:04:04 [ChrisL]
... like an 8 channel file
16:04:54 [ChrisL]
padenot: smpte is the same as wav extensible ordering
16:05:36 [ChrisL]
matt: they are different for 5.1
16:05:58 [ChrisL]
(we compare specs, for those who bought copies)
16:06:43 [ChrisL]
there are changes from 10 and above
16:06:56 [ChrisL]
hoch: wav does not support 8.2
16:08:05 [ChrisL]
ChrisL: if one is free and one is not, we should pick the freely available one
16:08:20 [ChrisL]
padenot: aac is patent encumbered
16:09:04 [ChrisL]
pad (checks ffmpeg)
16:09:12 [rtoyg]
https://www.ffmpeg.org/doxygen/3.0/group__channel__mask__c.html
16:09:13 [ChrisL]
padenot: (checks ffmpeg)
16:09:30 [padenot]
https://trac.ffmpeg.org/wiki/AudioChannelManipulation
16:10:11 [ChrisL]
padenot: my link has the standard layout
16:11:16 [ChrisL]
hoch: ffmpeg follows wav, not smpte
16:12:38 [ChrisL]
joe: we need ordering, not flag bits
16:14:37 [ChrisL]
ChrisL: I want the ordering in an appendix
16:15:05 [ChrisL]
padenot: and say it is the same order as wav extensible and ffmpeg, in an informative note
16:15:30 [ChrisL]
s/in an appendix/in our spec/
16:15:45 [joe]
https://github.com/WebAudio/web-audio-api/issues/1135
16:16:07 [ChrisL]
Topic: AudioBuffer constructor behavior is not defined
16:16:24 [ChrisL]
joe: oh the PR was merged. Closing
16:16:37 [joe]
https://github.com/WebAudio/web-audio-api/issues/1162
16:16:55 [ChrisL]
Topic: What happens to the `HTMLMediaElement`s or `MediaStream`s when the context is closed
16:18:43 [ChrisL]
padenot: you have both behaviours available depending on what you want
16:18:57 [ChrisL]
.mute or disconnect
16:20:48 [ChrisL]
rtoyg: spec is clear, chrome is wrong here
16:21:14 [ChrisL]
padenot: adapt behaviour of suspend (well defined) into close (not well defined)
16:21:23 [ChrisL]
rtoyg: I will send a PR
16:22:02 [ChrisL]
... by 1 July
16:25:02 [ChrisL]
rrsagent, make minutes
16:25:02 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/06/20-audio-minutes.html ChrisL
17:20:13 [ChrisL]
ChrisL has joined #audio
17:21:19 [hoch]
hoch has joined #audio
17:24:23 [rtoyg]
rtoyg has joined #audio
17:24:23 [joe]
joe has joined #audio
17:35:37 [mdjp_]
mdjp_ has joined #audio
17:35:44 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A%22Web%20Audio%20V1%22%20-label%3A%22V1%20Blocker%22%20
17:37:01 [joe]
https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Web+Audio+V1%22+-label%3A%22V1+Blocker%22+sort%3Acreated-asc
17:37:38 [ChrisL]
scribenick: mdjp_
17:37:41 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/246
17:38:13 [mdjp_]
joe any objections to deferring?
17:39:55 [mdjp_]
cwilso: at his point if we are trying to spec the current implementation it does not make sense to add side chaining. Side chaining will be moved to v.next as part of the work to develop a new dynamics compressor
17:40:34 [joe]
proposed lang: The compressor itself is being speced as far as practical for V1 as per #10. We plan to introduce a more powerful compression/expansion/side-chaining approach in the next rev of this spec that also is more specific with respect to its exact audio behavior (which is not possible for the current node).
17:42:36 [joe]
From F2F meeting: The current compressor design is quite limited and being speced as far as practical for V1 as per #10. We plan to introduce a more transparent and flexible compression/expansion/side-chaining/noise-gating approach in the next rev of this spec.
17:43:15 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/324
17:43:29 [joe]
https://github.com/WebAudio/web-audio-api/issues/324
17:44:50 [mdjp_]
rtoyg: when source and listener are at same loc on FF you hear both left and right, chrome just left. Update special case to LR
17:45:48 [mdjp_]
equal power on LR channels
17:50:03 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/353
17:53:53 [joe]
https://github.com/WebAudio/web-audio-api/issues/906
17:55:18 [mdjp_]
rtoyg: no constraint on the channel numbers. For current version constrain to 1 or 2 stereo or mono.
17:55:37 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/908
17:55:48 [joe]
https://github.com/WebAudio/web-audio-api/issues/987
17:57:20 [mdjp_]
rtoyg: padenot change spec to match current browsers and use max
17:58:18 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1080
17:59:16 [mdjp_]
joemove to v.next
17:59:28 [joe]
https://github.com/WebAudio/web-audio-api/issues/1081
18:02:37 [mdjp_]
joe: is thre a message generated at the end of each rendering q that can be used to update this value?
18:04:34 [mdjp_]
padenot: for all nodes send back the current audio param values at the end of the last renderd block
18:05:49 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1093
18:06:16 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1095
18:07:53 [ChrisL]
https://webaudio.github.io/web-audio-api/#widl-AudioBufferSourceNode-loop
18:08:04 [ChrisL]
The default value is false. If loop is dynamically modified during playback, the new value will take effect on the next processing block of audio.
18:12:18 [mdjp_]
cwilso: update looping section to be accurate and explain how the loop attribute works along with the modification of the loop attribute.
18:12:23 [mdjp_]
joe happy to take this on
18:12:38 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1104
18:12:50 [joe]
https://github.com/WebAudio/web-audio-api/issues/1104
18:14:53 [mdjp_]
rtoyg: simple definition of event time required. joe references twice in the spec cwilso could cause confusion with event.time
18:15:47 [mdjp_]
ChrisL: rename to audioparam time, joe audio param event time
18:16:42 [joe]
https://github.com/WebAudio/web-audio-api/issues/1139
18:17:04 [mdjp_]
padenot: needs to be fixed
18:18:11 [mdjp_]
padenot: changed ff to match chrome behaviour. Needs to be refleced in the spec.
18:19:24 [mdjp_]
padenot: invoke close, reject all promises. Same as navigating away from a page.
18:20:36 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1152
18:20:49 [joe]
https://github.com/WebAudio/web-audio-api/issues/1152
18:22:42 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1199
18:24:37 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1203
18:28:02 [joe]
https://github.com/WebAudio/web-audio-api/issues/1216
18:29:25 [mdjp_]
padenot: you should only set the buffer once.
18:29:40 [mdjp_]
rtoyg: ok with the current approach
18:30:25 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone
18:31:13 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1247
18:32:04 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1236
18:34:38 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1230
18:38:56 [mdjp_]
https://github.com/WebAudio/web-audio-api/issues/1226
18:41:27 [ChrisL]
https://github.com/WebAudio/web-audio-api/pull/1231
18:43:35 [ChrisL]
Topic: WebAudio v.next
18:44:15 [ChrisL]
https://github.com/WebAudio/web-audio-api/labels/Feature%20Request%2FMissing%20Feature
18:49:22 [mdjp_]
Moving to discussion for v.next structure.
18:50:19 [mdjp_]
How much code before spec - extensibility of using workers. Users can experiment -> establish requirement for native nodes.
18:50:50 [mdjp_]
Not everything needs to be incubated, some features are obvious requirements which have been moved from v.1
18:51:34 [mdjp_]
padenot: unification of media en/decoding, media recorder requested and issues exist.
18:52:37 [mdjp_]
padenot: wotwg streams for real time de/encode
18:53:15 [mdjp_]
padenot: web platform has improved since waapi design started
18:54:33 [mdjp_]
joe composite audio nodes as brought up by cwilso, creating abstract nodes from exiteing nodes
18:55:40 [mdjp_]
joe desire for access to native implementations (vst etc) #358
18:57:27 [mdjp_]
cwilso: security problems - no trust modal to accomodate this.
18:58:01 [mdjp_]
cwilso: vendors will cross compile to web assembly - UI handling required.
18:58:28 [mdjp_]
padenot: does this require a spec change cwilso we would be responsible for a web vst spec
19:00:02 [mdjp_]
padenot: what would be the problem with defining recommendations for web vst, not necessarily a web audio api change.
19:00:58 [mdjp_]
joe should we be responsible for a standard such as web vst?
19:02:05 [mdjp_]
padenot: composite nodes is a big missing part of the infrastructure
19:04:39 [mdjp_]
cwilso: working group needs to ensure that we have the tools + sandbox for this code to run.
19:06:42 [mdjp_]
joe idea of web vst is a good function to force us to ensure we have the correct tools.
19:08:05 [mdjp_]
hoch: vst, plugins, units - need to think about trademarks etc
19:11:59 [mdjp_]
padenot: in js f32 has to support denormals and cannot be disabled.
19:12:16 [mdjp_]
padenot: same issue in webassembly
19:14:16 [mdjp_]
ChrisL: request for a new node type that could pass frequency domain data between nodes
19:15:00 [ChrisL]
https://github.com/WebAudio/web-audio-api/issues/468
19:15:15 [mdjp_]
joe: how far are we from a working audio worklet
19:15:25 [mdjp_]
hoch: has a demo!
19:18:52 [mdjp_]
mdjp can we develop some themes to e covered by v.next so get an initial structure
19:19:14 [mdjp_]
eg hardware access, composability, vst etc
19:20:10 [mdjp_]
joe will entering CR generate significant new themes for v.next
19:20:24 [mdjp_]
ChrisL: probably not, more likely to be clarifications.
19:46:25 [joe]
joe has joined #audio
19:51:39 [ChrisL]
scribenick: joe
19:51:48 [ChrisL]
Topic: Web MIDI update
19:51:54 [joe]
cwilso: web midi update
19:52:20 [joe]
cwilso: happy to go through midi issues. they haven't changed much and a few minor things have been added.
19:52:51 [joe]
cwilso: I have a more concerning topic which is adoption of Web MIDI. We get continually hit on chrome team about Web MIDI usage being low and there's not another impl.
19:53:09 [joe]
cwilso: there's some concern that maybe we shouldn't be implementing this in Chrome bc we're the only people doing it
19:53:27 [joe]
cwilso: but I'm not trying to say "where's the magic switch that makes other browsers implement this"
19:54:09 [joe]
padenot: it's moving forward [at Mozilla] but it's a massive amount of code and we have no back end yet
19:56:26 [joe]
cwilso: I am fully confident that if there were a lot of action here I could get the editorial issues acted on in short order
19:56:51 [joe]
cwilso: I don't know how to bump that in priority, and I'd like to get Microsoft on board bc they only have one back end to write
19:57:55 [ChrisL]
https://www.midi.org/articles/midi-enhancements-in-windows-10
19:58:11 [ChrisL]
https://blogs.windows.com/buildingapps/2016/09/21/midi-enhancements-in-windows-10/#tJuYFiKKWp4a0Gkg.97
19:58:52 [joe]
cwilso: can we rev up adoption? bc if we don't, it might get removed from Chrome in favor of using the USB API
19:59:30 [joe]
joe: has anyone heard from Apple about this?
20:00:27 [joe]
cwilso: no.
20:01:25 [joe]
cwilso: the claim that MIDI is on the decline is not really true
20:02:41 [joe]
cwilso: some vendors would certainly be unable to continue if support for it were pulled
20:03:13 [joe]
cwilso: and there's a very different privacy model for arbitrary USB devices vs. MIDI usage
20:04:24 [joe]
joe: what would help here?
20:04:54 [padenot]
https://learningmusic.ableton.com/
20:05:00 [joe]
cwilso: there are some positives from s/w vendors like Ableton Learning
20:06:45 [joe]
cwilso: I need some help figuring out how to get other vendors to implement Web MIDI
20:07:00 [joe]
padenot: we said we would, and we've written 1000 lines of code at least
20:07:57 [joe]
padenot: next week will be the first summit at which I can sit down and talk with people about this
20:08:15 [joe]
padenot: there is now a very nice library that implements MIDI access across platforms
20:09:00 [joe]
padenot: I hope that I can find out that there is no showstopper (at the forthcoming summit)
20:09:35 [ChrisL]
https://github.com/musitdev/portmidi-rs
20:09:35 [joe]
padenot: I should have things to share after the next couple of weeks
20:17:36 [joe]
ChrisL: could we have a simple midi parser in the API? would that increase adoption?
20:17:58 [joe]
ChrisL: parsing seems pretty simple until you get into sysexes or interrupted messages
20:19:31 [joe]
cwilso: so we could do that but in order to do that we'd have to break compatibility w what we have today
20:19:42 [joe]
ChrisL: but couldn't we layer parsing on top of what we have today?
20:19:54 [joe]
cwilso: hmmm maybe
20:24:20 [joe]
cwilso: ChrisL, please file an issue on this
20:24:34 [ChrisL]
will do
20:24:44 [joe]
cwilso: it's related to another issue: #165
20:27:35 [ChrisL]
https://github.com/WebAudio/web-midi-api/issues/164
20:27:58 [hoch]
hoch has joined #audio
20:28:22 [ChrisL]
Define a "valid Midi message"
20:41:59 [rtoyg]
rtoyg has joined #audio
20:50:19 [ChrisL]
Dinner at http://dalirestaurant.com/
20:50:31 [ChrisL]
415 Washington Street, Somerville, MA 02143
20:50:49 [ChrisL]
19:30
21:15:50 [Zakim]
ChrisL, you asked to be reminded at this time to stop
21:20:20 [Zakim]
Zakim has left #audio