W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: MIDI Tracks and Sequences (API Proposal)

From: James Ingram <j.ingram@netcologne.de>
Date: Sun, 16 Sep 2012 19:04:03 +0200
Message-ID: <50560683.10101@netcologne.de>
To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
CC: Chris Wilson <cwilso@google.com>, Joseph Berkovitz <joe@noteflight.com>, public-audio@w3.org
Hi Jussi,

thanks for the reply. Chris' question seemed to need an answer, and I 
thought it might be a good idea to try writing down precisely what I was 
thinking. But I'm quite happy to leave it at that for the moment. 
Probably, it will turn into a library at some point.

>     Sequence: a collection of Tracks
>     Track: a collection of MIDIMoments
>     MIDIMoment: a collection of MIDIMessages having the same timestamp
>     I'm not sure, but maybe a MIDIMoment is what the current spec is
>     calling a MIDIEvent.
> Actually the MIDIEvent can contain MIDIMessages with different 
> timestamps. This is because the underlying API may already use 
> timestamped messages which lets the implementation give the messages 
> to the API consumer ahead of time if they're sent ahead of time. Also 
> because the thread might be blocked while messages were received, so 
> the implementations can group the messages that gathered during that 
> blocking and send them out in a single MIDIEvent to avoid overhead. 
> There's no wording of this in the spec yet, but that's roughly what 
> will be there.
My project is wanting to use the input device too, but (apart from the 
GUI) I haven't got as far as implementing that part of the code yet. 
I'll be moving on to that once simple playback (on the output device) is 
working. All info about MIDIEvent would be much appreciated. Any chance 
of a native implementation?

>     Perhaps it would help if I outline what I think ought to be in the
>     API [snip]
>     Constructors (empty objects):
>     Sequence()
>     Track()
>     MIDIMoment()
> MIDIMoment seems like an implementation detail to me, I don't think 
> the API consumer should have to keep collection of what messages share 
> the same timestamp.
MIDIMoments would allow MIDI programmers to bundle higher level 
concepts. For example "C4 played on a trumpet". One needs control over 
the order of the messages sent at any particular timestamp to do that. 
I'd like to be able to use such objects without having to track their 
relative positions.
This is a bit of a grey area: I have been unable to discover if the MIDI 
standard says anything about the minimum time which has to be left 
between a program change and a note-on. Windows Media Player has never 
given me any trouble in this respect, but on Quicktime it is (still?)  
quite possible for the program change to take effect _after_ a 
subsequent note-on arrives. (I'm on Windows.)


Received on Sunday, 16 September 2012 17:04:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:02 UTC