- 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