> In the first place, it is simply rhetoric to say that MIDI doesn't have
> semantics.

Beg pardon.  The MIDI standard defines, for instance, 127 "key 
numbers", which are deliberately left uninterpreted.  That is, those 
numbers simply refer to themselves.  It is up to the recipient of 
the message to come up with semantics.  More blatantly, message types
such as key pressure or sysex are completely devoid of meaning as 
far as the standard is concernen.  If anything, that warrants the 
claim that--with few trivial exceptions--MIDI, for the most part, 
doesn't have semantics.  In other words, if you take key numbers 
as degrees of a tempered chromatic scale, you comply to a an arbitrary
subset of MIDI, not the standard.

As far as duration goes, unless you get input from a MIDI file, 
there simply is no such thing.  That is, whatever your "Extended
MIDI" looks like, if it deals with durations instead of an untimed 
stream of events, it is incompatible with MIDI, not a proper extension 
of it.  In practice, while your protocol may allow translation 
to MIDI for certain data, it can't translate MIDI without additional
information.

Returning to the topic at hand, a csound "sequencer" whose underlying
representation of musical events requires durations is incompatible 
with real-time MIDI input.  Likewise, csound itelf is incompatible 
with real-time MIDI input unless you extend the "duration" of all 
csound instruments infinitely, thus in effect doing away with the 
duration requirement (the "MIDI kludge").

(`Real-time' here of course is used in its full sense of "without
knowledge about future events", not in the limited sense of a sequencer 
"playing back" a stored and thus known sequence in real-time.)