Re: Timing limitations when programming MIDI with Javascript

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

boolean  sendShortMIDIMessage (short status, short channel?, short? data1,
short? data2);

This lets you send:
out.sendShortMIDIMessage ( out.NOTEON, channel, notenumber, velocity );
out.sendShortMIDIMessage ( out.START );
out.sendShortMIDIMessage ( out.CHANNELPRESSURE, channel, aftertouch );
out.sendShortMIDIMessage ( out.RESET );
out.sendShortMIDIMessage ( out.PROGRAMCHANGE, channel, program );


> Additionally, I'm not sure why all the parameters in MIDIMessage are
> readonly?
>

 There's no good reason; to be honest, because I was too lazy to specify
what should happen if they're changed and to think about the possible
pitfalls. ;) This can be changed, I can fix that if we all agree and there
are no pitfalls, I see no reason not to.

Actually, I was wondering if it would be possible to create arrays of
MIDIMessages, to buffer them up with timestamps.

-C