Re: Timing limitations when programming MIDI with Javascript

On Mon, Jun 4, 2012 at 9:14 PM, Chris Wilson <cwilso@google.com> wrote:

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

I'll address this in the discussion about issue #105.


> 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);
>

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.


> Additionally, I'm not sure why all the parameters in MIDIMessage are
> readonly?
>

 There's no good reason; to be honest, because I was too lazy to specify
what should happen if they're changed and to think about the possible
pitfalls. ;) This can be changed, I can fix that if we all agree and there
are no pitfalls, I see no reason not to.