Re: [linux-audio-dev] Midi Mapper???

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Midi Mapper???
From: martijn sipkema (msipkema_AT_sipkema-digital.com)
Date: Fri Jan 04 2002 - 14:33:15 EET


> > Well... Please enlighten me (and perhaps other not so bright people).
>
> 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/off
> 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".

What if I want to update the operating system on my Kurzweil PC2x? I'm not
that familiar with SysV IPC message queues, but if they are anything like
the
POSIX ones, then there is a maximum message size for a queue and since
SysEX messages can be any size, they won't always fit. And how do I tell
an application that the MIDI messages it is sending can't be transmitted
because there is a very long SysEX messsage is being transmitted on the
same port? But should interleaving any message with MIDI realtime be
allowed (, I think it should). And shouldn't a modern MIDI api use
timestamps?

I have thought about this and haven't found a perfect solution, but I was
thinking about being able to open a port for short messages, sysex and
realtime messages seperately (and maybe a seperate short sysex?). this
would allow several application opening a port for short messages and
only one for sysex and realtime.

Also most MIDI drivers for professional interfaces will not be in the
kernel. I would really like to get my Unitor working with Linux but I
don't know how to do this with ALSA.

--martijn


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jan 04 2002 - 14:24:01 EET