W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: ACTION-33: MIDI charter proposal

From: Chris Rogers <crogers@google.com>
Date: Thu, 1 Mar 2012 12:06:27 -0800
Message-ID: <CA+EzO0=92FNtkhXQXx-ZGi-PE96XfCtytLSKpR24R9YgFTD_XQ@mail.gmail.com>
To: James Ingram <j.ingram@netcologne.de>
Cc: Chris Wilson <cwilso@google.com>, public-audio@w3.org
On Thu, Mar 1, 2012 at 2:26 AM, James Ingram <j.ingram@netcologne.de> wrote:

>  Hi Chris,
>
> Chris, I agree completely with your reservations about using the MIDI term
> "Realtime" in this context. These are messages stored in files, which are
> not necessarily ever sent in real time. MIDI (like JavaScript) has a few
> historical quirks...
> But I'm a bit wary of your use of the term "time-stamped". MIDI expects
> most of its message types to be executed *immediately* when they are
> received. They contain no temporal information.
>

James, I have to disagree with you here.  In the CoreMIDI API, events are
time-stamped (by the driver) with a high-resolution time:

// Please see <CoreMIDI/MIDIServices.h>

struct MIDIPacket
{
MIDITimeStamp timeStamp;
UInt16 length;
Byte data[256];
};

These timestamps are in relation to a high-resolution system clock and
can/should be used when recording MIDI performances into a sequencer, for
example.  It is not sufficient to simply get the "current time" on
receiving the event, because it can take some time (with significant
jitter) for the event to finally make it to the JavaScript
EventListener/Callback.

Chris
Received on Thursday, 1 March 2012 20:06:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 March 2012 20:06:59 GMT