Re: Timing limitations when programming MIDI with Javascript

On Tue, Jun 5, 2012 at 8:27 PM, Chris Wilson <cwilso@google.com> wrote:

> On Tue, Jun 5, 2012 at 4:10 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
>> On Tue, Jun 5, 2012 at 10:08 AM, Marcus Geelnard <mage@opera.com> wrote:
>>
>>> I think that we should be very careful if we want to provide shorthand
>>> methods for constructing/parsing messages, since that would make the Web
>>> MIDI API dependent upon another specification (right?), and probably even a
>>> specific version of another specification.
>>>
>>
>> Indeed, and this is an important design point because that allows for
>> authors to make libraries that depend on certain versions of the MIDI
>> Specification, while the Web MIDI API remains independent of such
>> restrictions.
>>
>
> 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.


>
>
>> By all means, if the shorthand/convenience functions can actually improve
>>> performance somehow (less GC, lower latency etc), it might be worth
>>> considering including them in the spec. Otherwise I don't see why shorthand
>>> methods can't be provided by a JS lib that can adopt new MIDI versions much
>>> quicker than a Web standard, for instance.
>>>
>>
>> Very much agreed! I don't see much performance/GC benefits of such a
>> shorthand method, hence I'm somewhat against adding it.
>>
>
> You don't see the performance delta between:
>
> out.sendShortMIDIMessage ( 0x90, channel, notenumber, velocity );
>
> and
>
> out.sendMIDIMessage( out.createMIDIMessage( 0x90, channel, notenumber,
> velocity ) );
>
> where a Javascript Object is created and has those four properties
> assigned to it, just to pass to another method that will unpack it to put
> it into the system's (or hardware driver's) form?  I agree it's not a huge
> perf delta, and it's O(n) on number of MIDI messages; it's still wasteful
> for the 95% case imo.
>
> 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?

Cheers,
Jussi