Subject: Re: [linux-audio-dev] Midi Mapper???
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Jan 03 2002 - 21:24:19 EET
>My solution to this problem is to use SysV IPC message queues. Each read/
>write to/from a message queue is atomic. That means as long as a each access
>of the message queue transfers a complete midi message (3 bytes for note on/of
>f
>or N bytes for sysex) then the message queue keeps each complete midi message
>together.
>
>Then all that is required is a library which wraps the acesses to the message
>queue enforcing the rule of "one complete midi message per queue access".
nice idea from a user-space perspective erik, but this doesn't take
into account the whole picture here. if the information is being
distributed to actual physical MIDI ports, then there needs to be
something that takes the message from the queue and delivers it to the
port's low level device driver. the code that does this would have to
be in the kernel, where the semantics of sysv message queues don't
exist (since the API is for user space).
besides, under POSIX, read(2) and write(2) are also atomic, in the
sense that N bytes of data delivered with either call will never be
"split". its not clear, therefore, that msq queues actually offer much
help with this.
and finally, its not the right answer anyway because of MIDI running
status. note on/off messages are not always 3 bytes because of this
feature. moreover, there are several single byte MIDI "real time"
messages that can arrive at any time, even in the middle of a non-real
time MIDI message. this means that defining "a complete midi message"
is much more complex than you are suggesting.
the MIDI specification includes a classic flow chart for a MIDI
parser, and if you become familiar with it (alas, its not online), it
can be seen that there are no short circuits around the "wire" level
of the MIDI protocol.
--p
This archive was generated by hypermail 2b28 : Thu Jan 03 2002 - 21:20:54 EET