Re: [Web MIDI API] send() method should also allow 3 shorts + timestamp

Hi Florian,  

On Sunday, 16 December 2012 at 22:55, Florian Bomers wrote:

> Hi Marcos,
> 
> IMO, a separate method for sending 3-byte MIDI messages does not
> really hurt (although it might even /cause/ confusion -- sometimes you
> need brackets, sometimes not...).
> 

Maybe, but web developers are well accustomed with working with overloaded methods. For example, jQuery's $( ) is overloaded to fire onload, run a CSS selector, create a set of nodes from a given input, and probably quite a few other things.    
> But it's just a wrapper method and
> can be implemented easily in an own method, or in a library. And
> chances are that you'll use more specific wrappers in your code
> anyway. 
> 

This is true. However, we should still aim to make the API as developer friendly as possible, so that they don't need to rely on libraries (as this ends up causing it's own set of issues).  
> Example:
> 
> void sendController(short ctrl, double normalizedValue /* 0...1 */)
> {
> ctrlMIDIDevice.send([0xB0 | ctrlChannel, ctrl,
> normalizedValue * 127]);
> }
> 
> (where ctrlMIDIDevice and ctrlChannel are declared elsewhere).
> 
> I guess you know that there are valid MIDI messages of any length.
Yes, absolutely. But the most common case is to send a message of 3 bytes, no? I see Chris argued heavily for that also in the bug you pointed to.  
> Personally, I'm very happy that the current webmidi API does not favor
> any particular length of MIDI messages (as many other MIDI API's do).
> Here, there is a good opportunity to encourage also advanced use of
> MIDI with Sys Ex, Show Control, etc.
> 

Agree. My motivation is to give flexibility on both.  
> For a long discussion of different flavors of the send method(s) --
> only for the very curious, I guess:
> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764>
> 

Thanks for the pointer! This was really helpful. However, it was not entirely clear from reading the thread why send(byte byte1, optional byte byte2, optional byte3) was not also added to the API. I thought Chris made a strong case for it, and it's the same argument I'm trying to make.

Received on Sunday, 23 December 2012 19:45:02 UTC