Re: Timing limitations when programming MIDI with Javascript

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.

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.

-C