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

MIDI files and streams -- was ACTION-33: MIDI charter proposal

From: James Ingram <j.ingram@netcologne.de>
Date: Fri, 02 Mar 2012 13:27:38 +0100
Message-ID: <4F50BCBA.1050202@netcologne.de>
To: public-audio@w3.org, Chris Wilson <cwilso@google.com>, Chris Rogers <crogers@google.com>
We seem not to have anything more to say about ACTION-33, so I've changed
the subject.

Answers in-line:

On Thu, Mar 1, 2012 at 12:06 PM, Chris Rogers<crogers@google.com  <mailto:crogers@google.com?Subject=Re%3A%20ACTION-33%3A%20MIDI%20charter%20proposal&In-Reply-To=%253CCAJK2wqXNR6jBsnDq6iRnTnhF_QCBQBbJ5v1uvATUKSe33w2ZTw%40mail.gmail.com%253E&References=%253CCAJK2wqXNR6jBsnDq6iRnTnhF_QCBQBbJ5v1uvATUKSe33w2ZTw%40mail.gmail.com%253E>>  wrote:
>  On Thu, Mar 1, 2012 at 2:26 AM, James Ingram<j.ingram@netcologne.de  <mailto:j.ingram@netcologne.de?Subject=Re%3A%20ACTION-33%3A%20MIDI%20charter%20proposal&In-Reply-To=%253CCAJK2wqXNR6jBsnDq6iRnTnhF_QCBQBbJ5v1uvATUKSe33w2ZTw%40mail.gmail.com%253E&References=%253CCAJK2wqXNR6jBsnDq6iRnTnhF_QCBQBbJ5v1uvATUKSe33w2ZTw%40mail.gmail.com%253E>>wrote:
>>   Hi Chris [Wilson],
>>  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.
>  [Chris Rogers] 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>

Beautiful docs [1]! This seems to be the Apple MIDI API.

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

On Thu, Mar 1, 2012 at 12:25 PM, Chris Wilson<cwilso@google.com  <mailto:crogers@google.com?Subject=Re%3A%20ACTION-33%3A%20MIDI%20charter%20proposal&In-Reply-To=%253CCAJK2wqXNR6jBsnDq6iRnTnhF_QCBQBbJ5v1uvATUKSe33w2ZTw%40mail.gmail.com%253E&References=%253CCAJK2wqXNR6jBsnDq6iRnTnhF_QCBQBbJ5v1uvATUKSe33w2ZTw%40mail.gmail.com%253E>>  wrote:

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

If its not part of the MIDI protocol itself, then it should probably be
hidden behind any new (JavaScript) W3C MIDI API. Yes?

>  [CW] This [means that] 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.

That is, effectively, what I (the Sanford Libraries) have been doing.

So I'll stick to my guns, and repeat that MIDI commands (in the MIDI
protocol) don't use time stamps. SMFs use the methods outlined by Anthony
yesterday [2]. These generally consist of projecting a series of nominally
regular ticks (of some sort) onto the other messages in the file.

I agree with Anthony that

>  With regard to any MIDI API specifications, supporting just MIDI beat
>  clock initially would satisfy most initial device inter-operation use
>  cases.

And I'd like to have a function in the JavaScript API which would allow me
to set the frequency with which the clock-ticks are sent. (i.e. give me
control over how fast to play a MIDI file.)

Apropos, here's Anthony's description of the MIDI beat clock:

>  MIDI beat clock - this is the most common device synchronisation method,
>  derived from good old analogue Sync 24.  Has basic start and stop signals
>  (there's a continue facility too but that is pretty rare in the wild) and
>  the running tick sent at 24 pulses per quarter note.

This is perfectly good MIDI language, but I have to say that my toe-nails
curl up when I see MIDI talking about "tempo" and "quarter notes". MIDI
uses "beat" and "quarter note" interchangeably -- as in "beats per minute"
and "quarter-notes per minute". This is the kind of confusion that got
20th century music notation into big trouble.

A "quarter note" is an *object* in space (a graphical symbol -->  SVG).
A "beat" is an *event* in time (something MIDI can generate -->  MIDI).

So "quarter notes per minute" and "pulses per quarter note" simply make no
sense. We should agree to use the word "beat" whenever we mean an event in
time. MIDI has age wrinkles...

Apropos age: I'm not very interested in the Standard MIDI File format. Its
a binary format, and there's a lot of software and better expertise than
mine out there for dealing with it. I think we only have to support it for
historical reasons.

The MIDI info in an SVG-MIDI file is exactly equivalent to (can be converted
into) the MIDI info in an SMF. Info from both file types can be read and
streamed to MIDI devices. I used to think that there ought to be a standard
way of encoding encapsulated MIDI[3], but am no longer sure that this is
the case. All one needs is an appropriate JavaScript interpreter. That's
something that needs thinking about.

All the best,

Received on Friday, 2 March 2012 12:28:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:58 UTC