On Mon, Jun 19, 2006 at 01:11:25AM -0400, Chapman Flack wrote:
> Hi,
> 
> The chap-midi branch has just been sync'd up to -current. It has been
> working reliably for me on the platform and with the hardware I am
> able to test.  Most of the changes (although I have continued making
> a few through this week) have been available in the branch for a few
> weeks now for others to try out.
> 
> It addresses a number of PRs (32441, 32442, 32567, 32588, 32651, 32694,
> 33590), improves performance of USB and UART links (in some case manyfold), 
> implements more of the MIDI semantics in midisyn, clarifies the interfaces
> between midi(4) and link drivers, and between midisyn and synth drivers,
> and between userland and the sequencer.
> 
> Although midisyn (and therefore internal synth chips) will still need
> to support more of the standard MIDI semantics to produce convincing
> output (lack of support for the percussion channel may be the most
> noticeable), they are now in a state where adding support for additional
> MIDI controllers should be straightforward, as should adding midisyn
> attachments to soundcard drivers whose synthesizer functions are not yet
> supported. (Anybody wanna do emuxki?)  USB or UART links to real external
> synths and controllers perform well enough for some kinds of real work.
> 

hi,

i've some naive questions about your midi driver. I've looked at sources,
and i see that raw devices don't wprovide the input raw midi stream. instead
the driver "normalizes" the input stream.

If there are no errors in the input stream, an application reading
/dev/rmidiN will receive something equivalent to the raw input stream. 
Is this correct?

However, if there is an error in the raw input stream, the driver will try
to correct it and the application reading from /dev/rmidiN will not see the
error. So, (for instance) it cannot tell to the user "there is an error" or
invalidate the track being recorded or take whatever "intelligent" action to
handle the error.

Also, since midi(4) devices are raw devices, any application using such a
device will decode the MIDI byte stream. Thus the job is done twice: once in
the kernel and once in the application. From the user-land developper point
of view, sometimes it is good to be able to test your midi application on
the "real" byte stream and to see what your hardware does when it receives
your "real" byte stream.

I think it is a very good thing to sanitize the input of an event orientated
device, like the sequencer; i still don't understand why it is also good for
the raw devices? Isn't the purpose of a "raw" device to provide the "raw"
stream ?

I'm asking this since i'm writing an user-land midi application that uses
the raw device (as opposed to the sequencer device) because it needs to do
the error handling. So my question is (from the user's point of view) how
should i do the error handling; is there something i missed? Should i change
my application?

Any advices are welcome!

kind regards,

-- 
Alexandre