Subject: Re: [linux-audio-dev] Midi Mapper???
From: martijn sipkema (msipkema_AT_sipkema-digital.com)
Date: Fri Jan 04 2002 - 14:44:25 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).
If we had a user space sequencer this wouldn't matter.
> 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 message queues aren't that useful when message sizes vary
a lot.
> 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.
Running status is not that much of a problem. A seperate 'queue' for MIDI
realtime could be used if you want interleaving.
> 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.
That's why I think a MIDI API that offers some multiplexing, but
still has some 'wire' in it, might be the best solution.
I really need that specification. It's just not only expensive but also
difficult to order, especially in europe :(.
--martijn
This archive was generated by hypermail 2b28 : Fri Jan 04 2002 - 14:34:15 EET