Re: Timing limitations when programming MIDI with Javascript

On Tue, Jun 5, 2012 at 10:08 AM, Marcus Geelnard <mage@opera.com> wrote:

> Den 2012-06-04 20:14:14 skrev Chris Wilson <cwilso@google.com>:
>
>
>  Was just about to hit send on a reply to James when Jussi's mail came in.
>>  +1 to what he said.
>>
>> The only thing I'd add is the the current spec treats DOMHighResTimeStamp
>> as if it has an innate zero-reference point (a la "milliseconds since UNIX
>> epoch"), which it does not - unless we explicitly refer to
>> window.performance.now().
>>
>> Also, in noting that the params are readonly, I'm starting to wonder if it
>> would be best to stay with this API but additionally have a "send short
>> message immediately" that doesn't use the MIDIMessage structure - it seems
>> like overkill to create a UInt8Array, call createMIDIMessage, etc.  when
>> what I really want to do is
>>
>> out.sendShortMessage( out.NOTEON, channel, notenumber, velocity );
>>
>> Definition would look something like
>>
>> boolean  createMIDIMessage (short status, short channel, short? data1,
>> short? data2);
>>
>
> Just a quick thought here... I have only had a quick look at the Web MIDI
> API specification, and I must admit I'm no MIDI expert (which is why I
> haven't provided any feedback so far). However, I think that one of the
> neat things about the spec, as it is today, is that it does not seem to
> limit itself to a specific version of the MIDI specification (somewhere
> around [1] ?).
>
> 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.


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

Anyway, here are two changesets [1] [2] (forgot to remove one readonly,
hence two commits) I just committed that remove the readonly restriction
from the MIDIMessage interface as well as other minor tweaks.

Cheers,
Jussi

[1] https://dvcs.w3.org/hg/audio/rev/db8f0473c76f
[2] https://dvcs.w3.org/hg/audio/rev/902e92d5d069