W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: MIDI spec updates, as per telecon

From: Chris Wilson <cwilso@google.com>
Date: Thu, 18 Oct 2012 07:05:45 -0700
Message-ID: <CAJK2wqX6Dnh+wxfZp+wfsGafgkLOkNjYmWLpkETR=E3_n0QjKg@mail.gmail.com>
To: Thierry MICHEL <tmichel@w3.org>
Cc: "public-audio@w3.org" <public-audio@w3.org>
Whoops!  Sorry.  Fixed.


On Thu, Oct 18, 2012 at 2:08 AM, Thierry MICHEL <tmichel@w3.org> wrote:

>
> Chris,
>
> there is a small HTML validation issue at
> Line 158, Column 10: No p element in scope but a p end tag seen.
>
>       </p>
>
> Thanks to fix.
>
> Thierry
>
>
> On 18/10/2012 01:42, Chris Wilson wrote:
>
>> I have updated the Web MIDI API specification, as per the discussion in
>> today's teleconference, with one addition.
>>
>> The changeset is here: https://dvcs.w3.org/hg/audio/**rev/f4727ce84474<https://dvcs.w3.org/hg/audio/rev/f4727ce84474>
>> .
>>
>> The updated spec is here:
>> https://dvcs.w3.org/hg/audio/**raw-file/tip/midi/**specification.html<https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html>
>> .
>>
>> I made the following edits:
>>
>>     - I expanded the overview section, making it clear that this API is
>> not
>>
>>     intended to cover semantic controls through MIDI (i.e. a solution to
>> the
>>     web of things problem), and also that this API is not concerned with
>>     Standard MIDI Files or General MIDI - that is, that it is concerned
>> with
>>     input and output, not "playback" per se.
>>     - I greatly expanded the introduction section to provide a more
>>
>>     table-of-contents style overview of the API, and also to describe in
>> more
>>     detail how the API is intended to function.
>>     - I essentially rewrote the Security and Privacy considerations
>> section
>>
>>     to describe the fingerprinting and access concerns in more detail,
>> and also
>>     (per conversation in telecon) to explicitly leave the model open.
>>  These
>>     three edits should resolve bug 19187.
>>     - I changed the sendMessage() method back to my suggested
>>
>>     three-parameter form, and explicitly excluded sysex from
>> sendMessage().  I
>>     expect further discussion on this point, but for our FPWD, I wanted
>> to have
>>     it this way as I was brainstorming the security and privacy
>> constraints,
>>     and I think it may be possible to use sysex as the "needs user
>> permission"
>>     switch - that is, to require user permission ONLY in order to
>> send/receive
>>     sysex.  I'm not positive this will be enough, but it will be easier to
>>     change it back than it would be to break variadic usage later.  ref:
>> Bug
>>     18764.
>>     - I explicitly made timestamps in MIDIMessage allowed to be set to
>> zero,
>>
>>     with the semantic of "send now", as per Bug 18760.
>>     - I added IDs to several elements in order to provide forward links,
>> and
>>
>>     I expanded some of the IDL constructs to better show the descriptions
>> of
>>     individual method parameters or members.  (no substantive changes.)
>>
>> -Chris
>>
>>
Received on Thursday, 18 October 2012 14:06:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC