Subject: Re: [long] Re: RFC: merge chap-midi branch
To: Chapman Flack <nblists@anastigmatix.net>
From: Alexandre Ratchov <alex@caoua.org>
List: tech-kern
Date: 06/28/2006 08:44:00
On Tue, Jun 27, 2006 at 06:22:54PM -0400, Chapman Flack wrote:
> 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 :).
> 

just out of curiousity; which apps are you talking about?

imho the midi parsing code is not so complicated i've seen quite few
apps that do the job; most of my hardware's firmwares do it properly.
There are things in the MIDI world that are much more complicated that
the parsing code that shouldn't takes more than 100-120 lines.

> >	- 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.
> 

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.

doesn't the midi sensing single-byte message fit in your definition of
midi message?

-- 
Alexandre