- From: James Ingram <j.ingram@netcologne.de>
- Date: Fri, 02 Mar 2012 13:27:38 +0100
- 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, James [1]https://developer.apple.com/library/ios/#documentation/CoreMidi/Reference/MIDIServices_Reference/Reference/reference.html [2]http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0312.html [3]http://james-ingram-act-two.de/svgScoreExtensions.html
Received on Friday, 2 March 2012 12:28:15 UTC