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

Re: MIDI files and streams

From: James Ingram <j.ingram@netcologne.de>
Date: Sat, 03 Mar 2012 19:34:06 +0100
Message-ID: <4F52641E.80205@netcologne.de>
To: public-audio@w3.org
Hi all,

Phil Burk said:

 > Timestamping has proven to be so useful in MIDI that the MMA is making
 > timestamps part of the protocol in the new "HD Music" standard.
[...]
 > As long as the API supports timestamps, then it would be possible
 > to write a good quality SMF player in JavaScript.

I'm still asking myself whether the timestamps should be hidden or 
exposed by the web MIDI API.
It might be easier to write a good quality SMF player in JavaScript if 
all that timestamping and buffering were well optimised and hidden. Do 
we really need more SMF players?

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.

Joe said:
> 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).
Agreed. I think that Javascript programmers should be released from the 
chore of working with clock ticks. We need to hide MIDI's wrinkles.
SMFs define their own "tempo" (say 100 beats per minute), and all I want 
is to be able to override that value somehow. 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.
My own choice would be to define a function which does not mention 
"tempo" but asks for a factor by which to multiply the default speed. 
(An SMFs "tempo" is not necessarily related to anything one actually 
hears!) But maybe there are enough SMFs out there whose "tempo" *is* 
perceptible. In that case a function for setting the tempo directly 
might be more suitable. Maybe we should have both.

Joe again:
> 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.
I'm afraid I didn't understand this. What would your "high-resolution 
real-time value in seconds" mean?
_____________

MIDI data in SVG-MIDI files should be overridable too. The MIDI data 
embedded in my SVG Chord symbols includes their default duration in 
milliseconds (there is no "tempo"). It would be very easy to override 
such durations while parsing them in Javascript.

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.
If you want to have two notes starting at the same time but ending at 
different times, you have to put them in different Chords. This is 
normal music notation usage.

So the web API should define a ChordMessage constructor and a 
Send(ChordMessage) function.

The Javascript parser would create ChordMessages from the data it finds 
in the SVG-MIDI file, make any changes to the ChordMessages' properties 
it wants, and then Send the message.

The code behind the API would do the necessary low level 
time-stamping/buffering etc.
I'm not sure how the system would allocate time for the Javascript 
parser's thread, but that shouldn't be the parser's problem.

This could be made to work, because a ChordMessage includes the 
following information which the underlying code can convert into low 
level MIDI messages with time-stamps:
   1. the time (in milliseconds from the beginning of the 
performance/click) at which the NoteOns should be performed.
   2. the Chord's duration in milliseconds, and
   3. whether or not to send a ChordOff when the duration expires.

Actually, a chord symbol can be "ornamented", so the ChordMessage would 
actually contain a sequence of (un-ornamented) ChordMessages. A detailed 
look at the ChordMessage definition can be left for later. This does 
not, however, change the general idea.

Joe again:
> 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.
+2! :-)

all the best,
James

-- 
www.james-ingram-act-two.de
Received on Saturday, 3 March 2012 18:34:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 3 March 2012 18:34:42 GMT