Alexandre Ratchov wrote:
> ok! i think that now i'm understanding your point of view; i didn't
> before.
> 
> for you a midi(4) device provides a stream of _midi messages_ that
> are passed to the application through the read(2) syscall. (as
> opposed to _midi byte stream_ with which the application has to
> deal). 
> 
> It just happens that the format of the provided messages is a subset
> of the midi protocol (no running status, no sensing, no unused data
> bytes), is this correct?

Yes - a form chosen because (a) the forms expected by the various link-
level drivers are all easily derivable from it, (b) it simplifies
development of new apps, while (c) it is consumable by legacy apps (though
it will never exercise some of the most bug-prone code paths in those apps,
and that really was part of the point :).

> 	- wach for midi acks; if there isn't an ACK after more than 300ms
> 	  then trigger the "error events"
> ...
> So, the only error that i want to handle properly is midi cables
> disconnects. This is likely to happen in real-time performance.

Ah! Then you've come to the right place. :)  You will find that event
signalled for you by a zero-byte read(2), i.e. a one-shot EOF indication,
much like the handling of ^D by termios(4).  You are free to continue
reading afterward; the channel will have reverted to non-Active-Sensing
operation unless/until another Active Sense is received.

Regards,
-Chap