Re: Timing limitations when programming MIDI with Javascript

On Mon, Jun 4, 2012 at 11:25 PM, Chris Wilson <cwilso@google.com> wrote:

> On Mon, Jun 4, 2012 at 12:50 PM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
>> On Mon, Jun 4, 2012 at 10:35 PM, Chris Wilson <cwilso@google.com> wrote:
>>
>>> On Mon, Jun 4, 2012 at 12:20 PM, Jussi Kalliokoski <
>>> jussi.kalliokoski@gmail.com> wrote:
>>>
>>>> On Mon, Jun 4, 2012 at 9:14 PM, Chris Wilson <cwilso@google.com> wrote:
>>>>
>>>>> boolean  createMIDIMessage (short status, short channel, short? data1,
>>>>> short? data2);
>>>>
>>>>
>>>> I agree, the createMIDIMessage is awkward for most use cases right now,
>>>> but it was designed to address all the use cases. I originally had an
>>>> overload similar to this in mind, I just haven't added it yet because I'm
>>>> not completely sure what the form should be (as in what arguments it would
>>>> take). This looks like a pretty clean form, but I would add the optional
>>>> timestamp as a last argument.
>>>>
>>>
>>> I would leave timestamps to the createMM path - because not all short
>>> MIDI messages have three bytes.  For example, program change, channel
>>> aftertouch...  I'd expected that if the parameters were null, they would
>>> not be sent.  In order to add timestamp and have it be uniformly usable, it
>>> would have to go at the front of the data bytes - and then, of course, you
>>> would have to specify it every time you wanted to send a note on/off
>>> message.
>>>
>>> Of course, not all messages have a channel either - so that should be
>>> optional - but some of the messages don't have a channel, but do need
>>> additional bytes (e.g. song select - actually, it's only song
>>> select/position pointer/MIDI Time Code and sysex that do this).  I think
>>> that would look okay.
>>>
>>> And GAH, I copied/pasted too aggressively.  I meant to say (presuming we
>>> define some constants):
>>>
>>
>> Hmm, for consistency, instead of constants we could just use a dictionary
>> (simpler too):
>>
>> MIDIAccess.createMIDIMessage("noteon", notenumber, velocity);
>> MIDIAccess.createMIDIMessage("start");
>>
>
> Simpler, but I'm not sure that's as efficient, and we use constants in Web
> Audio and elsewhere - and I still have a feeling authors are going to want
> to know the actual status codes.  Maybe I'm mistaken.
>

Yes, Web Audio API uses constants but I don't recall seeing much of them
elsewhere in the web APIs, canvas.getContext() uses a dictionary (although
in that case I think it wasn't a good idea, it's hard to feature test, but
doesn't affect this case), as well as document.createElement(),
getUserMedia() and so forth.

What are you referring to with efficiency? The speed of converting the
string to the number value? About the same as the overhead of the scope
lookup, object property solving and integer conversion for having it as a
property of some constant-hoisting interface.

boolean  sendShortMIDIMessage (short status, short channel?, short? data1,
>>> short? data2);
>>>
>>
>> What about we make the MIDIMessage properties writable, and then we could
>> just have a short form overload of createMIDIMessage:
>>
>> MIDIMessage createMIDIMessage (short status, short? data0, short? data1,
>> ..., short? dataX);
>>
>> And you could tinker the values you want to change if you need to change
>> them.
>>
>
> So you mean you'd actually do
> out.sendMIDIMessage( out.createMIDIMessage( out.NOTEON, channel,
> notenumber, velocity ) );
>
> Eh.  I still think the transient MIDIMessage object is unnecessary, and
> the single short send call is worth having.
>

I kind of disagree, because we either need a lot of different short calls
(ones that include timestamps, ones that don't, ones that have channels,
ones that don't) or horrible overloads no-one remembers. I'd go for letting
the cows pave the path again and see if some short form single-shot send
call takes prevalence and maybe standardize that later.

Cheers,
Jussi