See also: IRC log
<chrislowis> Bad connection.
<tmichel> could we start the agenda with issue about adding code for conformance requirement and testing ??
<tmichel> zami, who is here ?
<gmandyam> Giri Mandyam, Qualcomm Innovation Center, joining the call
<jussi> Zakim: ??P66 is me
<chrislowis> tmichel: added some code to track requirements in the spec as per RFC keywords.
tmichel: added spec updates to hilight RFC2119 MUST MAY etc
<chrislowis> ChrisLilley: thanks!
tmichel: and then XSLT it to find
the testable assertions
... won't be all the tests we need, just a subset
<scribe> scribenick: chrislilley
tmichel: did a search and
replace, so there are false positives
... asked chris rodgers to clean up the result as the author
knows which ones are really required
chris: will get keywords in but don't want to start from the auto search and replaced version
tmichel: just wanted to show what
is possible
... plh will present some testing guidelines in two weeks
chris: ok but will take more time than we have til the next deadline
<scribe> ... continued review of them as i proceed
tmichel: use uppercase MAY for 2119 and lowercase may for general English
chris: some places the test may have to be a manual test, because it may be a high level aspect which can't be done with an automatic test
chrislowis: priority at the moment is to make testing and conformance easy for implementors
tmichel: agree we don't have a direct mapping between keywords and number of tests
chris: agree it has value
tmichel: (garbled)
... styling will not remain in the final spec, the code will
but won't trigger visible styling change
chris: ok that covers everything, did not like the styling, and its better to pick out the keywords manually
ChrisLilley: good to link tested assertion styling with :target so it hilights when you link to it
<ehsan> https://github.com/alankligman/webaudio-conformance
<chrislowis> ChrisLilley: Alan.
ehsan: have checked stuff into github and will maintain it
??: looking for feedback on test and how to submit them
chris: in webkit we use an
offline context. set up a rendering graph and give it a
callback, which gives n audio buffer
... the javascript can check that and send a pass/fail
message
... important to have that in the spec, for testing
ack: ys we need that for any sort of useful testing, not just high level API testing
chrislowis: need that to test in an implementation independent way
chris: manual tests can be error
prone and time consuming
... a dozen or so manual tests is fine
ack: also want to discuss test submission process
ChrisLilley: can use incoming directories. Shepherd is a way to manage tests
tmichel: each WG does it differently
ack: want submission process as
easy as possible so we get lots of submissions. Need a large
number of tests to get implementor attention
... currently its not easy to see if something is in the spec
or not
chrislowis: important to get tests early
ehsan: any problems with the test framework? can it be announced on the public list?
(yes)
tmichel: we should dedicate a
full telcon to testing
... on 19 Dec
<ChrisWilson> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19803
cwilso: fingerprint does not
guarantee uniqueness
... need a fallback, as windows gives no way to associate a
physical midi port gets the same unique identifier
... generally the case for any hardware. each one can be
further queried, can identify by manuf and type, but they can
get switched
... or plugged in a different order
shepazu: if this a windows limitation or a midi one?
cwilso: its not related to the midi spec, its how the system enumerates devices
shepazu: could there be some unique ID that a device sends out?
cwilso: yes, but distinguish
between devices and midi adapters. same thing over usb, but not
over DIN midi
... MIDI protocol only talks about communication with
endpoints
... using sysex it can be improved a bit
... don't want to reorganise the interfaces each time you start
a DAW
... soec says SHOULD because we can't guarantee
uniqueness
... index is simply a list of ports
... in chromeOS we have not got those problems
... think it has unique identifiers, not sure if they are
portable across machines
ChrisLilley: sounds OK as a SHOULD if some platforms can't provide it
cwilso: made unique identifiers
by concatenating manuf, model and index
... reasonable thing to do but can't be relied upon
... have other ways to ask about the device, maintain a MIDI
port reference but they are not saveable
zz: but they would persist across a session
shepazu: can it be relied upon on other platforms
cwilso: maybe but not universally
xx: APIs can give a huge amoubt
of info, like persistent tegistry information, device
descriptors API
... big pool for generating a unuique ID
cwilso: need to document what
happens to fallback if it fails
... session stores IDs but also do index and name storage
... so session can be restored later
... not ideal, but better than total failure
... looking for guidance, good feature but unreliable so needs
well specified failure behaviour
... jussi seems to think its usefull enough right now
jussi: case where you check if
you have a certain name at the same index as previously, may
have enough info to create a unique ID
... create fingerprint from data plus how many devices you have
with the same information
cwilso: so two interfaces of the same type show up named the same and you store MOTU1 and MOTU2 for example
jussi: yes
shepazu: keep it in, mark at
risk, ask for feedback
... can drop it later
... and we can document why we dropped it, if we do
<ChrisWilson> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19975
cwilso: when restructuring,
looked at making onMessage be a single message, so we dont
neeed a midi message at all
... long thread, some good discussion. different is the
callback represents a single midi messages rather than a bunch
at once
... not that crazy, event firing overhead is ok and its how
windows midi api works also
... can simplify now and add event handler for multiple
messages later if needed
ChrisLilley: can timestamt two messages that form a 14-bit message?
cwilso: yes, get two callbacks
for MSB and LSB, may not have same the same timestamp
... still undefined what you do if one of the messages is
missing. same for sysex, osx core midi api lets you have a midi
packet with a partial sysex
... usbmidi and windows midi does not give partial
messages
... on js processing end its much easier to only get complete
messages
... correct way is to buffer one message until the rest
appears
ChrisLilley: seems like a good simplification
jussi: I agree
... no proven cases where it is better to have only multiple
messages
cwilso: found some scenarios where slow processing gives a buffer issue. but it does make it easier to write basic software
jussi: yes, solve the harder problem when we have it
chrislowis: summarise these discussions in the bugs, please
cwilso: will do, and hiope to
publishbefore year end
... other bug outstanding is to state everywhere we throw
exceptions
... and add lots of examples
shepazu: two issues, one is that
kames from intel can't join at this time, second is that this
slot is taken up by two other huge groups and the bridge gets
full
... so people end up unable to join
... working on more capacity, but this slot is overbooked
chrislowis: change next year, then
ChrisLilley: great to avoid the clash with CSS
shepazu: will make a poll on the new times
<scribe> ACTION: shepazu to make a call time poll [recorded in http://www.w3.org/2012/12/05-audio-minutes.html#action01]
<trackbot> Created ACTION-53 - Make a call time poll [on Doug Schepers - due 2012-12-12].
shepazu: difficult to organise a
time due to global scope
... some groups alternate early and late calls, for example
<chrislowis> ChrisLilley: thanks so much for scribing, much appreciated!
<chrislowis> ChrisLilley: great job!
chris lowis will you send out the minutes?
<chrislowis> ChrisLilley: I think I can do that tomorrow, yes.
ok
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/tm: /tmichel:/ Succeeded: s/tm: /tmichel:/g Succeeded: s/xx/chris/ Succeeded: s/??/ack/ Succeeded: s/ack/ehsan/ Found ScribeNick: chrislilley Inferring Scribes: chrislilley Default Present: [Mozilla], Thierry, chrislowis, +44.303.040.aaaa, gmandyam, ChrisL, jussi, +1.408.772.aacc, jernoble, chris, +1.862.201.aadd, ChrisWilson, Doug_Schepers Present: [Mozilla] Thierry chrislowis +44.303.040.aaaa gmandyam ChrisL jussi +1.408.772.aacc jernoble chris +1.862.201.aadd ChrisWilson Doug_Schepers WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 05 Dec 2012 Guessing minutes URL: http://www.w3.org/2012/12/05-audio-minutes.html People with action items: shepazu[End of scribe.perl diagnostic output]