W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Timing limitations when programming MIDI with Javascript

From: Chris Wilson <cwilso@google.com>
Date: Tue, 5 Jun 2012 10:10:03 -0700
Message-ID: <CAJK2wqVxLX7ALgexZrJTnsPogZh0QuyFEF94q_5k5Ugjx5gDiA@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, James Ingram <j.ingram@netcologne.de>, public-audio@w3.org
On Tue, Jun 5, 2012 at 12:08 AM, Marcus Geelnard <mage@opera.com> wrote:

> Den 2012-06-04 20:14:14 skrev Chris Wilson <cwilso@google.com>:
> Just a quick thought here... I have only had a quick look at the Web MIDI
> API specification, and I must admit I'm no MIDI expert (which is why I
> haven't provided any feedback so far). However, I think that one of the
> neat things about the spec, as it is today, is that it does not seem to
> limit itself to a specific version of the MIDI specification (somewhere
> around [1] ?).
> I think that we should be very careful if we want to provide shorthand
> methods for constructing/parsing messages, since that would make the Web
> MIDI API dependent upon another specification (right?), and probably even a
> specific version of another specification.

Perhaps Tom would like to weigh in, but the MIDI spec has had the concept
of short messages and long messages since v1, IIRC.  In fact, pretty much
everything IS short messages (1-3 bytes) except system exclusive - and I
don't expect there would be changes to the concepts of note on, note off,
controller changes at this point.  I don't think providing a short message
vs long message API is tying us to a particular version of MIDI - in fact,
the OLD Windows API had exactly this concept
midiOutLongMsg <http://msdn.microsoft.com/en-us/library/dd798474(v=vs.85)>,
where the latter requires creating a buffer and preparing it, and the
former does not.

Received on Tuesday, 5 June 2012 17:37:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:04 UTC