W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Timing limitations when programming MIDI with Javascript

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Mon, 4 Jun 2012 22:50:08 +0300
Message-ID: <CAJhzemWyypi7donmTvhr7GC6fw3UaXsqHEpy2LYf_qyWmWxXqA@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: James Ingram <j.ingram@netcologne.de>, public-audio@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 June 2012 19:50:37 GMT