Peter Enderborg writes:
> Jaroslav Kysela wrote:
>
> > On Fri, 1 Mar 2002, Peter Enderborg wrote:
> >
> > > Paul Davis wrote:
> > >
> > > > >Yes! And the device that is using running status is alsa rawmidi device.
> > > >
> > > > What makes you think that? AFAIK, the raw MIDI device code does no
> > > > parsing of MIDI data at all ...
> > >
> > > Parsing? It sends raw midi on a stream. That stream is _from_ alsa seq.
> > > It is doing the bandwith optimize by it self. I do the parsing.
> >
> > Ok, please, specify your problem in a more detailed way. At least, we need
> > to know about midi paths in your applications and what sequencer clients
> > are involved to help you. And yes, there could be a problem with running
> > status, because our converts work with it.
> >
>
> I don't know how to be more specific. I have a program that listen to a raw midi
>
> stream generated by alsa. But I try.
>
> I have a midisport 8x8. It have a serial port. I have a computer linux. Alsa
> don't have
> driver for the unit. So I have writen a daemon that open the snd-card-virmidi
> with
> snd_rawmidi_open(). I have also writen a processor that handels event on a
> sequencer level
> to interface my Roland MCR-8 with varius applications, synths. Roland MCR-8 a
> "multicontroler"
> but it is not progammable. It have 9 knobs,9 slides a lot of buttons an a dialer
> wheel.
> But not all apps have the same mapping of events. So the processor mapps them i
> the way I like
> to have them. But it is only control messages. On the daemon side that
> interfaces to the
> raw midi stream in encapsulate them in to midimans format and sent them over the
> serial port
> to the unit. The unit is decapsulate them and send it to the right midi port.
> But when I open the
> virmidi device in raw mode. I is already assuming that I know what was the last
> command. In my case
> a control message. Is this clear enougth? I know that this a very common midi
> problem, but it should not have to be a problem within the same machine.
>
I think you want to do this differently.
Your program for patching the midisport into the alsa sequencer
should connect to the midisport driver on one side and the sequencer
event interface on the other side and use the alsa/snd_midi_event.h
routines to translate between the two.
So, as you read raw midi bytes from the midisport driver, use
/* encode from byte stream -
return number of written bytes if success */
long snd_midi_event_encode(snd_midi_event_t *dev,
unsigned char *buf,
long count,
snd_seq_event_t *ev);
to encode the incoming byte stream into snd_seq_event_t and send the
events the sequencer using the event interface.
As you receive events from the sequencer, use
/* decode from event to bytes -
return number of written bytes if success */
long snd_midi_event_decode(snd_midi_event_t *dev,
unsigned char *buf,
long count,
snd_seq_event_t *ev);
to decode the incoming event stream into a midi byte stream which you
can then write() to the midisport.
You will need to send a reset on the midisport side when you first
connect to get the snd_midi_event_t state synchronized to the incoming
running status.
But you won't see any running status from the alsa side because the
event interface fully identifies each event. snd_midi_event_decode
will use running status on the decode side, but the stream generated
will start from the first event decoded.
Does this help?
-- rec --
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
