On Thu, Jun 29, 2006 at 10:18:09PM -0400, Chapman Flack wrote:
> Alexandre Ratchov wrote:
> >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.
> >...
> >- apps that want something close to the "midi 1.0 specification" should
> >  have access to the byte stream (/dev/rmidi or similar)
> 
> You are here drawing close to suggesting that what midi(4) provides is
> distant from the MIDI specification; we may be failing to communicate.
> 
> When you open an rmidi device, what you are allowed to write on it is
> precisely what would be valid to write on a MIDI 1.0 DIN cable. Your
> write will incur EPROTO if-and-only-if you attempt to write anything
> else.
> 

i agree here; the only point is whether or not midi apps, will have
access to active sensing and to aborted messages (nobody should care
for the latter at least if read(2) doesn't fail)

i'm understanding your point; As an user-land midi developper i've just
tryed to friendly present you my personal point of view.

> A significant change took place in OpenBSD almost two years ago exactly,
> when a major rewrite of its midi stack did away with virtually all of
> the protocol processing done in midi(4) and introduced instead the
> empty-pipe semantics that you are advocating here. A later corresponding
> update to OpenBSD's midi.4 man page changed the title from "device-
> independent MIDI driver layer" to "raw device independent interface to
> MIDI ports" and added the language "Data received on the input port is
> not interpreted ... data issued by the user program is sent as-is...."
> The source of the changes was Alexandre Ratchov.
> 
> So the question we are talking about is not so much:
> 
>  Why did Chap diverge from an empty-pipe "raw" semantics?
> 
> as:
> 
>  Why did Chap choose to refine the existing OSS semantics rather than
>  to introduce the raw model brought by Alexandre into OpenBSD?
> 
> ... and we've covered some of the reasons earlier in this thread.

yes, i've contributed some midi patches to obsd; i've tried to keep
compatibility with both NetBSD and Linux (ALSA raw devices pass active
sensing and aborted messages as-is). I don't want to talk here about
obsd's midi driver, the topic of this thread is to comment your work
and i'm doing this from the point of view of a midi user.

i've no more comments. i'm looking forward for your midi work; feel
free to contact me if you have midi-related announces, suggestions,
questions...

cheers,

-- 
Alexandre