Re: Timing limitations when programming MIDI with Javascript

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).


>  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.

-C