Roger E Critchlow Jr wrote: > 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? >
Well. I guess it do. I will give it a try. It should work. What about non midi snd_seq_event_t. The internal alsa stuff, like subscribe? > > -- rec -- > > _______________________________________________ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel -- foo! _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
