Re: MIDI files and streams

Leaving aside the programming language idioms, I agree with your points
here, Phil. You've sketched the essential functionality that a MIDI API
needs, minus clutter. As you said, chords, tempo, and all manner of other
musical concepts can be layered on top easily.

Except for one disagreement: I think we should stay away from introducing a
new MIDI-specific temporal unit (the "tick"). I don't see the need to have
anything other than seconds. In my view that extra unit just makes for an
impedance mismatch with the audio APIs and introduces an extra idea. Of
course timestamps are quantized in reality but the programmer shouldn't be
worrying about that.

...j
On Mar 3, 2012 6:37 PM, "Phil Burk" <philburk@mobileer.com> wrote:

>
>
> On 3/3/12 10:34 AM, James Ingram wrote:
>
>> I'm still asking myself whether the timestamps should be hidden or
>> exposed by the web MIDI API.
>>
>
> I think timeStamps are an important feature that should be exposed and
> available to the programmer.
>
>  Do we really need more SMF players?
>>
>
> We need for it to be possible to write a good SMF player in JavaScript on
> top of the code MIDI API.
>
>  Does the MMA's "HD Music" standard mean that hardware MIDI devices are
>> going to do the message buffering themselves? We should be careful not
>> to define a web API which is soon going to become obsolete.
>>
>
> MIDI is not being replaced by HD. MIDI is sufficient for most applications
> and will continue to be useful.
>
>  Here, roughly, is how I think the web API might work:
>> A Chord symbol is the lowest level of symbol in an SVG-MIDI file that
>> can respond to a click.
>> So the web API should define a ChordMessage constructor and a
>> Send(ChordMessage) function.
>>
>
> I don't think we should include high level music concepts in the MIDI API.
> If the MIDI API is built correctly then one can build chords, tempo,
> measures, etcetera on top of it.
>
> The API can be very simple. Something vaguely like these pseudo-code
> definitions:
>
> int WebMIDI_GetDeviceCount();
>
> String WebMIDI_GetDeviceName(int deviceIndex);
> String WebMIDI_GetDeviceManufacturer(**int deviceIndex);
> int WebMIDI_GetDeviceType(int deviceIndex);
> // other queries may be useful
>
> int WebMIDI_OpenDevice(int deviceIndex);
>
> double WebMIDI_GetCurrentTime();
>
> int WebMIDI_WriteMIDI(
>    int deviceIndex,
>    byte[] data,
>    int numBytes
> );
> int WebMIDI_WriteTimedMIDI(
>    int deviceIndex,
>    byte[] data,
>    int numBytes,
>    double timeStamp
> );
>
> int WebMIDI_CloseDevice(int deviceIndex);
>
> I know that JavaScript does not have byte[]. My Java-centric world view is
> showing through. These pseudo-code functions would need to be mapped into a
> JavaScript style API with better names. I just wanted to show that the
> functionality can be pretty minimal.
>
> It might be better to use an integer timestamp. Something like 1/16 msec
> ticks is enough resolution for most applications.
>
> On top of these core functions it would be easy for others to write
> utility functions  like:
>
> int MyMIDITools_NoteOn( deviceIndex,
>    channel, noteNumber, velocity, timeStamp );
>
>
> I have not written enough JavaScript to know whether the MIDI input should
> be a callback or a polling read.
>
> > If the code behind the web MIDI API is able to stream an SMF at
> > all, then it should not be too difficult to let me do that.
>
> Unfortunately SMF is not a streaming file format. Format 1 SMF files are
> multi-track and have to be read entirely before playing. They are the most
> common. Format 0 SMF is a single track and could be read like a stream but
> it is not really a stream.  Luckily most SMF files are small, 2-100 KB. So
> you can just read the whole file then play it from memory.
>
>
> Phil Burk
> www.mobileer.com
>
>