Port manufacturer and version set to null

Jazz does not support the port manufacturer or version fields, and these
are both nullable, so they are set to null.
Added JSLint directives; MIDI Input events now working.

Known Bug: (Todo next) lib/Sequence is not working. Problem is with 'this'.
MIDI constants are now read-only

The constants defined in lib/Event.js are now read-only. An exception is
thrown if an attempt is made to change their values.
Small error correction in HTML
Moved constant definitions from Event.js to Constants.js

Constants.js is a new file.
Completed migration of constants to new file.

Still working on Sequence and sequenceToSMF().
Score performance now working

The MIDI_LIB library is now performing scores correctly, including the
calculation of the correct data values for pitchWheel event construction
and the saving of performances as Standard MIDI Files.
TODO: move the code for creating subsequences out of MIDI_LIB into the
Assistant.
Code for creating subsequences moved out of Sequence.js...

and into Assistant.js. This is much better, since it reduces the size of
Sequence's API, which is now much better suited for general purpose
Sequence applications.
Currently debugging assisted performances.
Other known bugs: the performance buttons are not working correctly
after the first start.
Bug fixed: All markers' visibility now set correctly...

after re-setting performance options. Before the bug was fixed, an
end marker visible somewhere in the score was not being made invisible, so
it appeared on the left edge of the page (its zero position).
Bug fixed: performing events changed their timestamps.

In tick(), a += should simply have been a +.
This lead to repeat performances not starting correctly.
Just tidied up jiAPControls.js. No code changes
Reorganized the use of Sequences - non-assisted working

There is now only one Event object for each event, and these are shared
between different sequences and moments. This should be simpler and use
space more efficiently -- important when files get really big. Also
simplifies the concepts, which makes maintenance easier.
Non-assisted sequences are working perfectly, including performances
which start after the beginning of the score.
Assisted performances still need some work, but it usually means making
existing code simpler...
Moment.timestamps are now read-only - important!
Reorganised moment.msPositionInScore and event.timestamps.

This should now be consistent. PositionInScore values are now all
readonly. Timestamps apply only to events, and are not readonly.
Non-assisted performances are working correctly (including
starting later than the beginning of the score), so Sequence.js should
now be correct.
Work still has to be done on assisted performances.
Small corrections to Sequence.js
Backup before beginning major timestamp revolution.

In future, Events are not going to have individual timestamps. Instead, each moment will have a (volatile) timestamp in addition to its (constant) msPositionInScore.
This is going to lead to smaller memory use and faster performance because
   a) setTimout() will be called once per moment rather than once per event in tick().
   b) timestamps will be set/reset much less often when starting/ending performances.

Moment.timestamp is always going to be either undefined or an *absolute* DOMHRT time.
Backup commit: Sketch using absolute moment.timestamp

This nearly works, but it might be even better using "relative
timestamps". Try the following TODO:
In score.getSequence() set a moment.msDelay attribute to the
delay between the moment and the previous moment in the
same track. In nextMoment(), the next moment is retrieved
using msPositionInScore. The current absolute timestamp can
be maintained for each track independently using the
(sub)sequence's startNow value.
This algorithm should avoid recalculating timestamps at the
beginning of each playSpan...
Completed timestamp revolution for non-assisted performances.

All files except jiAssistant.js should now work (NEEDS TESTING).
To recapitulate:
Event has been renamed Message.
Messages no longer have timestamps (except temporarily while
converting sequences to Standard MIDI Files), but moments do.
Every moment has a read-only msPositionInScore attribute
which is set when the moments are constructed in
score.createSequence(). (The msPositionInScore attributes take
account of the performance speed option, but this fact can be
ignored in the MIDI lib files.)
At Moment construction time, moment.timestamp attributes are
set to UNDEFINED_TIMESTAMP. The timestamp values are set
properly (to absolute DOMHRTime) in Sequence.nextMoment()
so that they exist both for tick() and in a recorded sequence (if any).
If the performance is being recorded, the moment.timestamps in
the recorded sequence are set relative to the beginning of the
sequence before converting it into a Standard MIDI File. After
conversion, the moment.timestamps in the recording are reset
to UNDEFINED_TIMESTAMP.
If the sequence is not being recorded, moment.timestamps are
reset to UNDEFINED_TIMESTAMP inside tick(), as soon as they are
no longer needed.
Non-assisted performance debugged and running

I have as yet only tested with Study 2b3. Selections of tracks and spans
are running okay.
As in the past, recordings play back faster than the live performance.
Possibly change the timestamps again to their real values when they
are sent. This needs looking at carefully to see how big the delays
actually are. Maybe enable two types of recording...
Improvements to non-assisted performance. Debugged pausing.

The pause button now works in non-assisted performances.
Tried setting timestamps to record the real time at which messages
were being sent, but tracks strangely became asynchronous! This
needs more thought.
Windows Media Player still plays recordings faster than the original
performance. Maybe this is a bug somewhere between
WMP and DOMHRT?
TODO next: Get the Assistant working.
Current state. Previous history discarded.