Re: Timing limitations when programming MIDI with Javascript

On Tue, Jun 5, 2012 at 12:22 AM, Chris Wilson <cwilso@google.com> wrote:

> On Mon, Jun 4, 2012 at 1:57 PM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
>> 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.
>>
>
> Right, but the MIDI API actually does translate to numbers in the actual
> transport; there's an actual reason
>
>>
>> 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.
>>
>
> True.  But the developer can also use well-known MIDI constants (e.g. 0x90
> for note on).
>

Yes, of course, I was suggesting the dictionary as an addition to the
numerical format. But I'm not sure that's necessary either. I'd just go
with the numerical format, a JS library can easily provide the necessary
constants.


>
>
 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.
>>
>
> I was suggesting one long-form, that followed the create/send pattern, and
> one short-form as above (boolean  sendShortMIDIMessage (short status, short
> channel?, short? data1, short? data2);)  I think in this case the overloads
> are natural, the channel is only there when it's needed except for the
> transport controls, and I wouldn't put timestamps in the short form at all.
>  I think the case of "send this MIDI short message immediately" is a very
> common one;  I can of course just write a shim for it, though.
>

Exactly. Usually in the web APIs it's avoidable to specify something that
can be simply written in JS, it adds to the spec complexity and begs for
the question "why not this short form too/instead?" and we really have no
answer to that question, other than gut feeling. When we have actual data
on what kind of usage patterns arise we can start thinking about things
like this, imho.

Cheers,
Jussi