Re: ACTION-33: MIDI charter proposal

Right.  This is true of the Windows APIs as well; when received and sent,
the messages are time-stamped.  This is for use by the underlying MIDI
driver and hardware; it's not part of the MIDI protocol itself.  This does
make mean the driver can provide low-level accuracy of timing for
recording, for example, even if the event sink process is processor-bound.

You can typically just set the time stamp to "now" for outgoing messages if
you don't want this control.

On Thu, Mar 1, 2012 at 12:06 PM, Chris Rogers <crogers@google.com> wrote:

>
>
> 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
>
>