Re: Timing limitations when programming MIDI with Javascript

On Tue, Jun 5, 2012 at 12:32 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> Um.  MIDI is at 1.0.  It was originally issued in 1982; I do know from the release
>> notes <http://www.midi.org/techspecs/midispec.php> that there haven't
>> been any changes that would affect the level of spec we've been talking
>> about since at least 1995.  I think worrying about non-backward-compatible
>> changes to MIDI is a red herring.  Again, perhaps Tom would like to comment.
>>
>
> Ugh, sorry, Marcus's comment made me think about SMF somehow. Yes, you're
> correct.
>

The General MIDI spec has seen a few changes in that time too, but I don't
think we're going to dig in to GM specifically.

Also, somewhat separate issue - Jussi, I think the ordering of parameters
>> on createMIDIMessage is not optimal.  You have
>>
>> short status, Uint8Array? data, DOMHighResTimeStamp? timestamp, short?
>> channel
>>
>> I'd expect it to be
>>
>> short status,  short? channel, Uint8Array? data, DOMHighResTimeStamp?
>> timestamp)
>>
>> based on usage and the common MIDI messages' use of channel and data.
>>  And is your intention that a developer could explicitly pass "null" for
>> timestamp, and it would be interpreted as now?
>>
>
> OK, now that I have my thoughts back on track, let's rethink this. I was
> just thinking about the same thing as I was re-reading through my spec
> today, it's much more intuitive that way, I'll change it in a bit. And yes,
> the timestamp can be null, so if we add a short form, I still think it
> should have the timestamp.
>
> I'm wondering what should we do with messages that don't have channels,
> i.e. 0xF0 - 0xFF? Should status codes be masked with 0xF0 so that you'd
> specify System Common Messages and System Realtime Messages using the
> channel? Or should we just drop the channel to be a part of the status
> code? Or have a special case for setting the status code to >= 0xF0?
>

I'd thought a lot about that.  There's no answer I'm entirely happy with -
 but in looking at all the MIDI message types that aren't channel-specific
(i.e. there's no channel set - the System Common and System Realtime
messages from http://www.midi.org/techspecs/midimessages.php) - they are
system-exclusive, Time Code/Song Position Pointer/Song Select, or transport
control- type messages.  I think those are far less common than the channel
messages (note on/off, aftertouch, pitch bend, continuous controllers,
etc.).

I'd considered whether we should really break apart the status byte as it
is currently in message status and channel; overall, I think it's
worthwhile doing it the way you have, because I'd wager most JavaScript
developers aren't used to frequently doing bit-masking operations, even
though that leaves us with a channel parameter that's unnecessary some of
the time. (I.e. "If the status code is >= 0xF0, then the channel parameter
is not used, and can have any value without effect.")  Since MIDIMessage's
members are all writable, for sysex messages you'd probably be constructing
your own data Uint8Array outside the creation param anyway.


-C