Re: Timing limitations when programming MIDI with Javascript

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.


> 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?

-C