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