- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
 - Date: Mon, 4 Jun 2012 22:50:08 +0300
 - To: Chris Wilson <cwilso@google.com>
 - Cc: James Ingram <j.ingram@netcologne.de>, public-audio@w3.org
 - Message-ID: <CAJhzemWyypi7donmTvhr7GC6fw3UaXsqHEpy2LYf_qyWmWxXqA@mail.gmail.com>
 
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");
> 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.
> 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 );
>
> Actually, I was wondering if it would be possible to create arrays of
> MIDIMessages, to buffer them up with timestamps.
>
Sure, that would be relatively simple if we just make the properties of a
MIDIMessage writable:
msg1.timestamp = msg2.timestamp = performance.now();
Cheers,
Jussi
Received on Monday, 4 June 2012 19:50:37 UTC