Re: [MIDI]: collapsing MIDIMessage into MIDIEvent

Hey James,

Definitely, we need to add a bunch of (informative) JavaScript code
examples to the spec.  It's on my list.  :)


On Thu, Nov 29, 2012 at 3:12 PM, James Ingram <j.ingram@netcologne.de>wrote:

> Chris,
>
> Thanks for the answer. I'm kicking myself for having hit my send button a
> bit early last time...
>
> Let's just say that I now understand things much better than I did, and
> your answer put the icing on the cake. Hopefully I won't be the only one to
> have profited from reading it.
>
> There's obviously going to be a need for a short explanation of how to use
> the API from Javascript. Maybe even a small standard library. That being
> the case, I don't think its crucial to Javascript programmers which way you
> go. If anything I'm now leaning towards removing MIDIMessages from the API.
>
> All the best,
> James
>
>
> Am 29.11.2012 19:43, schrieb Chris Wilson:
>
>> James,
>>
>> I think you missed it, but we explicitly moved away from having two
>> different send methods, and using MIDIMessage in send, specifically so that
>> we wouldn't need to have a constructor for MIDIMessage, and so that we
>> wouldn't have two different forms of what is essentially the same function.
>>  Using one form, with a sequence parameter and a timestamp, enables us to
>> have timestamping on short and long messages, variable-length messages, and
>> only one send method.
>>
>> Note that you DON'T really have to think about UInt8Arrays, on purpose -
>> when you call send, it takes a sequence, so it can be anything that
>> functions like an array, which means you can call:
>>
>> send( [ 0x90, 0x45, 0x27 ] );
>>
>> (the [] creates an Array in JS.)
>>
>> On the other end, when you receive a MIDI message (regardless of the
>> MIDIMessage change), although the parameter is a UInt8Array, you can again
>> just treat it like an array of numbers, you don't have to think about it
>> being UInt8Arrays
>>
>> EXAMPLE USING PROPOSED REMOVAL OF MIDIMESSAGE:
>> onmessage( event ) {
>>   if (event.data.length < 4) {  // "short" MIDI message
>>     switch ( event.data[0] & 0xf0 ) {
>>       case 0x90: // Note on!
>>         notenumber = event.data[1];
>>         velocity = event.data[2];
>>       ... // etc, etc
>>     }
>>   } else {
>>     // sysex!
>>   }
>> }
>>
>> SAME EXAMPLE, USING CURRENT MIDIMESSAGE:
>> onmessage( event ) {
>>   for (var i=0; i<event.messages.length; i++ ) {
>>     if (event.messages[i].data.length < 4) {  // "short" MIDI message
>>       switch ( event.messages[i].data[0] & 0xf0 ) {
>>         case 0x90: // Note on!
>>           notenumber = event.messages[i].data[1];
>>           velocity = event.messages[i].data[2];
>>         ... // etc, etc
>>       }
>>     } else {
>>       // sysex!
>>     }
>>   }
>> }
>>
>> The main reason for using UInt8Array is it will be more efficient when
>> using sysex, particularly when doing file storage.  But the average user
>> shouldn't have to think about it.
>>
>> I know the API is relatively small already.  But the fewer objects there
>> are, the fewer object lifetimes there are to manage, as well as the less
>> developers have to understand in order to be productive.  If there's
>> significant value, then I'm okay with additional API; I don't see much
>> significant value right now, and (see above) the code needed for a simple
>> note handler becomes more complex.
>>
>>
>> On Thu, Nov 29, 2012 at 3:24 AM, James Ingram <j.ingram@netcologne.de<mailto:
>> j.ingram@netcologne.de**>> wrote:
>>
>>     Sitting on the user side, I'd like to keep MIDIMessage objects in
>>     the API (separate from MIDIEvent).
>>
>>     1. The API is actually very small. Increasing its size by
>>     including a separate MIDIMessage does not make the API
>>     significantly more difficult to understand.
>>
>>     2. I want to have a MIDIMessage constructor for creating messages,
>>     and I'd prefer that to be handled by the API. I don't want to have
>>     to think about UInt8Arrays. If MIDIMessages exist (for that
>>     reason), it makes sense to expect to find them in MIDIEvents too.
>>
>>     Question: Does a MIDIMessage constructor need to be put in the spec?
>>
>>     Possible suggestion (ignore at your pleasure): It would be
>>     convenient if MIDIOutput could also send a MidiEvent. I seem to
>>     remember that the 'send' function used to be called
>>     'sendMIDIMessage'. Maybe that change should be reverted, and
>>     MIDIOutput could also be given a 'sendMidiEvent' function.
>>
>>     best,
>>     James
>>
>>
>>
>>
>
>