- From: James Ingram <j.ingram@netcologne.de>
- Date: Sat, 03 Mar 2012 19:34:06 +0100
- 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 UTC