W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: [Web MIDI API] send() timestamp

From: Marcos Caceres <marcos@marcosc.com>
Date: Fri, 14 Dec 2012 20:27:51 +0000
To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Cc: public-audio@w3.org
Message-ID: <1D01D7DD1AED410188D5942F95FC3500@marcosc.com>


On Friday, December 14, 2012 at 8:12 PM, Jussi Kalliokoski wrote:

> 
> Not necessarily. Some platform MIDI APIs have an internal clock and allow MIDI messages to be sent and processed ahead of time, so when you receive a MIDI message, it might not be supposed to take effect immediately. The timestamps being synchronized with DOMHRTF essentially let you leverage/emulate this feature without exposing meaningless details about the underlying API, such as its internal clock.
So 2 things: 

1. the spec is not clear with regards to this, as it says: "Let event be a newly constructed MIDIEvent, with the timestamp attribute set to the time the message was received by the system". That doesn't seem to match what you described above. 
2. how common is this use case? or how common are these devices? (I honestly don't know, but it would be good to have some data).

I presume most people will just want a little delay in sending data. Here is two things I just made for fun by changing the API to use delay instead of timestamp:

for(var i=2, fib=[0,1]; i<12; i++){ 
fib[i] = fib[i-2] + fib[i-1]; 
output.send([0x91, fib[i] ,0x5f], (100 * fib[i])); 
}


for (var l = 128, i = 0; i < l; i++) { 
var value = Math.floor(l * (Math.sin(i * 0.09)) + l) / 2; 
output.send([0x91, value ,0x5f], (50 * i)); 
};

  
The current API would require me to prefix everything with performance.now() or an alias - which is inconvenient for my use cases above. 

I'm still not sure what the most common use cases for this API will be. 

-- 
Marcos Caceres
Received on Friday, 14 December 2012 20:28:19 UTC

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