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

A few further observations/underlinings...

On Mar 2, 2012, at 3:35 PM, Chris Wilson wrote:

> 
> On Fri, Mar 2, 2012 at 4:27 AM, James Ingram <j.ingram@netcologne.de> 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?
> 
> As others stated - the API exposing this info is fairly critical to getting timing accuracy.

Right, it's the main thing we need the API to do besides transport of the actual MIDI data.

>  
> 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.
> 
> The MIDI >protocol< doesn't use timestamps.  MIDI APIs typically do, in order to minimize latency errors.

James is correct, and the big value of the APIs is that they perform the low-level scheduling essential to interpretable input and performable output.  The timestamps amount to envelope-level data around chunks of MIDI protocol data.
>  
> 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.)
> 
> You've actually hit the nail on the head - it's relatively easy to write code that would inject a beat clock from the API.  However, you're quickly going to want to interface with that beat clock - e.g., have the transport controls, time code, etc, all directly represented - and that becomes a fairly large and complex API surface in order to enable all possible DAW/sequencer/synth designs.

I don't think the clock tick frequency is really important to a useful MIDI API (as opposed to an SMF file, where it is crucial).  A high-resolution real-time value in seconds (not ticks) I think is ideal, because different applications will interpret or generate real-time timestamps in very application-specific ways. We should not try to have the API deal with some sort of quantized musical time dimension, any more than we would do so in the Audio API for scheduling sound output.

>  
> 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.
> 
> Noted.  I'll try to avoid saying "quarter note", which I don't think is used outside of SMF.

Agree here -- I don't think there is any notion of "quarter note" in the idea of a timestamp, and we do not need SMF's notion of "pulses per quarter note".

... .  .    .       Joe

Joe Berkovitz
President

Noteflight LLC
84 Hamilton St, Cambridge, MA 02139
phone: +1 978 314 6271
www.noteflight.com