On Wed, Jun 28, 2006 at 04:28:33PM -0400, Chapman Flack wrote:
> Alexandre Ratchov wrote:
> >>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
> >
> >if i'm not mistaken, 
> >
> >	cat /dev/rmidiN >/tmp/xxx
> >
> >will stop working on the first error, but will not restart
> >working when the cable is plugged again.
> 
> s/error/Active Sense timeout/ and yes, exactly; that is nearly verbatim
> the example from the man page. The point here is, if you are using a
> general utility like 'cat' rather than some midi-aware program, your
> choices for what you would want it to do in this case are limited to
> about two. You can get a file xxx that contains the known good data up
> to a break in communication, or you could get a file xxx that contains a
> time warp at some unspecified spot where some unknown amount of data
> dropped out and you don't know what happened to the state. If the
> first is what you want, use the command above.  If it's the second you
> want, use
> 
>  while cat; do :; done </dev/rmidiN >/tmp/xxx
> 
> If what you want is more sophisticated than either of those, 'cat' might
> not be what you want.  But you might notice two things:
> 
> 1- the second choice actually extends rather easily to things like
>   while cat; do print -r "$RESET_ALL"; done </dev/rmidiN >/tmp/xxx
>   or
>   while cat >/tmp/xxx$((segno++)); do :; done </dev/rmidiN
> 
> 2- if I had not implemented Active Sense as I did, you might not have
>   even this range of choices available to you as simple one-liners of
>   Unix tools.
> 

i really like these one liners. But imho, users may want to have
something as close as possible to the "midi 1.0 specification". This
spec is here since more than 20 years and is still actively used by
modern hardware. It is also mature and quite well documented.

If you make /dev/rmidiN event driven, there will be 2 event driven APIs
(/dev/rmidi and /dev/sequencer) and no simple byte stream API, as
described in the midi spec.

IMHO:

- naive apps that don't want to parse the byte stream should use the
  event orientated device (/dev/sequencer)

- apps that want something close to the "midi 1.0 specification" should
  have access to the byte stream (/dev/rmidi or similar)

From application point of view, parsing the stream is not hard. It will
be sad to disable access to the byte stream because some buggy apps are
misusing /dev/rmidiN instead of using the event API (/dev/sequencer).
 
Finally, note that some other OS are using the byte stream for their
raw midi devices, so from compatibility point of view it would be nice
if midi(4) could provide the raw midi byte stream. 

But, all this is just my personal opinon.

kind regards,

-- 
Alexandre