Re: Timing limitations when programming MIDI with Javascript

Hello James!

This could be realized by having either
> 1) two different functions in the API:
> creatMidiMessage(...) and createTimeStampedMIDIMessage().
> rather than a single function with an optional argument as at present in
> Midibridge's
> midiAccess.createMIDIMessage(...)
> or
> 2) some way of declaring globally that the programmer wants to use
> time-stamps of some sort.
>

The spec currently says that the timestamp is optional, being filled in as
the current time. However, I don't see the value of having two types of
MIDIMessages, with and without timestamps. The DOMHighResolutionTimeStamp
is currently specified to be a double, and the cost of having a double in a
struct is as much as having a pointer instead in 64bit system, which is not
that much, even for a smartphone. The timestamp will be the least of the
implementations' memory concerns, I'd believe. Garbage collection isn't
necessarily a problem, since implementations will probably just use JS
wrappers for the messages and the data will actually be stored in an
underlying struct, and MIDI isn't exactly one of the highest traffic
protocols anyway.


> I've been investigating the limitations on timing in Javascript
> applications:
> 1. According to the W3C standard, the delay set in setTimeout() will never
> be less than 4 milliseconds [2]. In practise, the lower limit can be much
> larger [3].
> 2. The time interval in setInterval() is measured in milliseconds, so
> there are limits on the rates at which it can be used to send MIDI Clock
> events. (MIDI defines the rate at which MIDI Clocks are sent in
> *microseconds*. MIDI-Clocks are usually sent event every 20 milliseconds or
> so.)
>

Yes, this is exactly why timestamps are quite essential in a MIDI API that
will be in a JavaScript environment, they allow you to make the messages
happen as accurately as possible, i.e. ahead of time, so that you don't
have to rely on unreliable timing systems such as setTimeout().


> 3. I suspect that multithreading comes in here somewhere...
>

Yes, multithreading is something we need to talk about, I just haven't
formed my own opinion yet either. E.g. currently there's no great way to
process MIDI messages in a worker, for example you can't create MIDI
messages in a worker (no MIDIAccess), and I'm not sure making MIDIMessage a
non-[[NoInterface]] (i.e. global) is a very good idea, the global scope is
polluted enough as it is. What we could do, however, is that
sendMIDIMessage() would accept JavaScript objects that have all the
properties of a MIDIMessage.

Cheers,
Jussi

P.S.

> [1] https://github.com/abudaan/MIDIBridge/issues/1
>
Regarding this, I believe the reason Quicktime would react slowly to patch
change commands is that as it's processing the soft-synth output as buffers
(probably big ones to have minimal performance overhead), it might be just
disregarding a patch change that occurs in the middle of the buffer and
apply it before the next buffer.