Re: [Alsa-devel] Rawmidi bug or missed feature?
Roger E Critchlow Jr wrote: > Peter Enderborg writes: > > > > Roger E Critchlow Jr wrote: > > [ ... ] > > > > 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? > > > > Hmm, hadn't thought about it. You can look at the event type and > decide whether it's worth decoding, or just hand it to the decoder > and see if events which don't translate to midi just go away by > themselves, or you could look at the source for the library and see > if snd_seq_set_client_event_filter can do the work for you. > Im playing with it now. Realy nice. But there are some feature that are missing I think There are some undefined messages within the midi spec. The bytes F4, F5,F9,FD are undefined. Right now the parser ignores them and that make's thinks a little harder for me... An idea is that alsa could encapulate them in a own variable length message. Otherwise we can not be transparant! (or have I missed something?) > > -- 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
Re: [Alsa-devel] Rawmidi bug or missed feature?
Peter Enderborg writes: > > Roger E Critchlow Jr wrote: [ ... ] > > 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? > Hmm, hadn't thought about it. You can look at the event type and decide whether it's worth decoding, or just hand it to the decoder and see if events which don't translate to midi just go away by themselves, or you could look at the source for the library and see if snd_seq_set_client_event_filter can do the work for you. -- rec -- ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
>How can we get the same performance i userspace? For me it is the >processor/OS schedule that gives the limit for that, and in kernel we >get >the hardware as the limit. there are two things done by the sequencer: a) routing/multiplexing this is mostly a matter of code design and memory management, and can be handled just as well in user space as in the kernel, perhaps even better (other libs can be used, for instance). there is almost nothing i can think of relating to this work that requires or even benefits from a kernel side location. b) scheduling the kernel has no special access to system hardware for timing that is not available to a root-enabled or CAP_RESOURCE-enabled task. the default system timer that the vast majority of sequencer users will use is of much worse resolution than some of the alternatives such as the RTC and a PCM audio clock. however, both of these sources (as well as the default system timer) are available to user space processes. there is a small overhead involved, on the order of 2-10 microseconds, if that. Since the sequencer would have to run with these permissions to be useful, as a user space process it has the same scheduling capabilities as it does in the kernel (for our purposes; obviously, it can't schedule processes in the same way as the OS task scheduler, but then for that matter, neither can the existing kernel sequencer). the processor has no part to play in scheduling except for executing code. fast processors don't schedule faster other than in the sense that they execute the scheduling code (whether its in user space or not) more or less quickly. By putting the sequencer in user space we: a) remove a large and necessarily complex piece of code from the kernel, nearly always a good thing b) allow it to be developed more flexibly (code errors don't cause system panics or hangs) c) can make it more modular d) can port it to non-Linux systems more easily e) can extend it to work within or alongside other designs more easily --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
Paul Davis wrote: >How do you solve the problem with sharing hardware then? I don't. I intend to wait for (and contribute too, if I can) what I consider the correct solution: a) sequencer genuinely split into: 1) a router/multiplexer 2) a scheduler b) sequencer moves into user space As I've said before, I don't consider the current kernel-side implementation of the sequencer, nor its merging of two completely different functions, to be in anyone's interest. I think that Frank was (like myself and everyone else) somewhat "blinded" by the fact that OSS put the sequencer in the kernel, and we did not know that it was possible to get similar performance in user space. How can we get the same performance i userspace? For me it is the processor/OS schedule that gives the limit for that, and in kernel we get the hardware as the limit. For the time being, I have hardware solutions that work for me when I need to do complex MIDI routing (i.e. dedicated h/w MIDI patchbays), and I never run multiple apps using the same port. --p -- foo!
Re: [Alsa-devel] Rawmidi bug or missed feature?
>How do you solve the problem with sharing hardware then? I don't. I intend to wait for (and contribute too, if I can) what I consider the correct solution: a) sequencer genuinely split into: 1) a router/multiplexer 2) a scheduler b) sequencer moves into user space As I've said before, I don't consider the current kernel-side implementation of the sequencer, nor its merging of two completely different functions, to be in anyone's interest. I think that Frank was (like myself and everyone else) somewhat "blinded" by the fact that OSS put the sequencer in the kernel, and we did not know that it was possible to get similar performance in user space. For the time being, I have hardware solutions that work for me when I need to do complex MIDI routing (i.e. dedicated h/w MIDI patchbays), and I never run multiple apps using the same port. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
Paul Davis wrote: > >It is the api for midi programming. I don't have to think about > >active sensing, streaming or anything on the low level. And I get > >tools for routing the data as I like. I thougth that you should know > >the concept. Almost everything is in realtime. But some mappings i > >done in the time domain as well. For example the dialer. > > I don't use the sequencer for anything. I don't agree that its "the > API for MIDI programming". Perhaps I should just keep my mouth > closed. Roger seems to have better suggestions > How do you solve the problem with sharing hardware then? > > --p -- foo! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
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
Re: [Alsa-devel] Rawmidi bug or missed feature?
>It is the api for midi programming. I don't have to think about >active sensing, streaming or anything on the low level. And I get >tools for routing the data as I like. I thougth that you should know >the concept. Almost everything is in realtime. But some mappings i >done in the time domain as well. For example the dialer. I don't use the sequencer for anything. I don't agree that its "the API for MIDI programming". Perhaps I should just keep my mouth closed. Roger seems to have better suggestions --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
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
Re: [Alsa-devel] Rawmidi bug or missed feature?
Paul Davis wrote: > >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. > > You have a program that uses the sequencer to read MIDI data. That's > totally different from a program that uses the raw MIDI interface to > read MIDI data. This is very, very important. > > >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(). > > This makes no sense at all to me. snd_rawmidi_open() is a way to > get access to an ALSA low level, raw MIDI driver. For example, my > trident card has a MIDI port on it, and the trident driver contains > code to deliver and receive data from the port. If I want to > read/write that data stream, I would use snd_rawmidi_open(). > Yes, and my device is a midisport. > > But snd_rawmidi_open() has nothing to do with the sequencer, or with > virmidi. virmidi exists to make sequencer ports available via the raw > MIDI API so that programs which don't know about the sequencer can > still read and write data to it. > I do. I is a connection. I gets a client ID. So it have very mush to do with the sequencser. > > If there is no ALSA driver for the unit (or for serial MIDI - I am not > sure if we have such a thing, do we?), then why would you be calling > snd_rawmidi_open()? > There is a serial driver. But it dont handle the same protocol as midisport. So how should I connect my device so I can use the midisport to talk to my synths? Rawmid on a snd-card-virmidi gives one way. Show me a better way instead of say that im wrong. > > >I have also > >writen a processor that handels event on a sequencer level to > >interface my Roland MCR-8 with varius applications, synths. > > Why are you using the sequencer for this? It is the api for midi programming. I don't have to think about active sensing, streaming or anything on the low level. And I get tools for routing the data as I like. I thougth that you should know the concept. Almost everything is in realtime. But some mappings i done in the time domain as well. For example the dialer. > > > --p -- foo! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
>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. You have a program that uses the sequencer to read MIDI data. That's totally different from a program that uses the raw MIDI interface to read MIDI data. This is very, very important. >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(). This makes no sense at all to me. snd_rawmidi_open() is a way to get access to an ALSA low level, raw MIDI driver. For example, my trident card has a MIDI port on it, and the trident driver contains code to deliver and receive data from the port. If I want to read/write that data stream, I would use snd_rawmidi_open(). But snd_rawmidi_open() has nothing to do with the sequencer, or with virmidi. virmidi exists to make sequencer ports available via the raw MIDI API so that programs which don't know about the sequencer can still read and write data to it. If there is no ALSA driver for the unit (or for serial MIDI - I am not sure if we have such a thing, do we?), then why would you be calling 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. Why are you using the sequencer for this? --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
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. > > Jaroslav > > - > Jaroslav Kysela <[EMAIL PROTECTED]> > Linux Kernel Sound Maintainer > ALSA Project http://www.alsa-project.org > SuSE Linuxhttp://www.suse.com > > ___ > 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
Re: [Alsa-devel] Rawmidi bug or missed feature?
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. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project http://www.alsa-project.org SuSE Linuxhttp://www.suse.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
On Thu, 28 Feb 2002, Peter Enderborg wrote: > I have a program that read's from a raw midi device. In midi there are > some simple compression. It is assumed that if the data flow is correct, > and the data should be interpreted as paramaters to previus command if > it's not a new command. But when I open a raw midi stream I can get in > to the stream without having the "previus" command. Is there any way to > do a query or reset the stream so I can get that command? If it's only > one midi channel sending the same type of command it will never get in > to sync! RawMidi devices don't interpret MIDI data in any way. So, you get exactly what's on input. Or are you refering virmidi devices? Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project http://www.alsa-project.org SuSE Linuxhttp://www.suse.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
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. > > > >It's not the roland device since I > >get them correct to the user_code. And how do I force the rawmidi device > >to stop sending running status, > >and that is the original question! > > I would have thought that if its not the Roland that is doing it, then > its the sequencer. > > --p -- foo! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
>get them correct to the user_code. And how do I force the rawmidi device >to stop sending running status, BTW, are you talking about running status, or active sensing? --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
>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 ... >It's not the roland device since I >get them correct to the user_code. And how do I force the rawmidi device >to stop sending running status, >and that is the original question! I would have thought that if its not the Roland that is doing it, then its the sequencer. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
Paul Davis wrote: > >This is the configuration: > > > >Roland MCR-8->midi-device->alsa-seq->user_code->alsa-seq->raw_midi > > this is a crazy, wierd setup! but i'll try to just let that be. i > suspect you don't mean "raw MIDI" the way its meant in ALSA. > What so weird about it? The user_code map some event's from the MCR-8 in to other. (Control to control, different values on the parameter. For example to get the locators and jog to work with Cubase) And the raw midi socket is sent to a midiman interface with no alsa driver. > > >So how far back should I need to reset? The communication roland and > >alsa-seq is in sync and my user-land code is sending > >snd_seq_event_t. > > you need to get this figured out. how is your user-land code sending > snd_seq_event_t if you're using the raw MIDI interface? i think you're > using the sequencer interface, and referring to "raw" MIDI just > because you're looking at MIDI messages. > No. My user_code is using seq API. > > I guess that my problem will disapear if I turn > >active-sening-on and that is what I going to try. > > no, that will not get rid of it. > > all MIDI devices are allowed to use running status any time they want. > if something hooks into an ongoing MIDI data exchange, and it needs to > be able to understand what is going on, there is absolutely zero > choice: a MIDI reset is required so that the transmitter stops using > running status for at least one message and the data stream becomes > parseable. > > now, as to what should issue that reset - thats a different > question. one might suggest that the ALSA sequencer should do so as > soon as it connects to an inbound port. but how can it? its ports are > uni-directional - it has no way of knowing that it should issue a MIDI > reset on a different port so that the input data stream on *this* port > becomes parseable again. > > thats why many good MIDI devices have a way to do a "MIDI reset" at > the user's request, precisely to deal with this kind of situation. its > certainly present on my Miditemp Matrix MIDI router. > I guess roland are not good then. > > i don't understand what your application is doing, but if you plan on > connecting to an ongoing data stream, be prepared to reset. > > >That will not help my reading. The device is in sync with alsaseq and > >there shuld not be needed to reset the transmitter. And even if I > >do. The merge of midi streams could be smart enough to see that it is > >of the same type. > > I don't understand any of this. "sync" and "type" have nothing to do > with what is going on. You need to force the transmitting device to > stop using running status for at least one message so that correct > parsing can begin. > Yes! And the device that is using running status is alsa rawmidi device. It's not the roland device since I get them correct to the user_code. And how do I force the rawmidi device to stop sending running status, and that is the original question! > > --p -- foo! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
>This is the configuration: > >Roland MCR-8->midi-device->alsa-seq->user_code->alsa-seq->raw_midi this is a crazy, wierd setup! but i'll try to just let that be. i suspect you don't mean "raw MIDI" the way its meant in ALSA. >So how far back should I need to reset? The communication roland and >alsa-seq is in sync and my user-land code is sending >snd_seq_event_t. you need to get this figured out. how is your user-land code sending snd_seq_event_t if you're using the raw MIDI interface? i think you're using the sequencer interface, and referring to "raw" MIDI just because you're looking at MIDI messages. I guess that my problem will disapear if I turn >active-sening-on and that is what I going to try. no, that will not get rid of it. all MIDI devices are allowed to use running status any time they want. if something hooks into an ongoing MIDI data exchange, and it needs to be able to understand what is going on, there is absolutely zero choice: a MIDI reset is required so that the transmitter stops using running status for at least one message and the data stream becomes parseable. now, as to what should issue that reset - thats a different question. one might suggest that the ALSA sequencer should do so as soon as it connects to an inbound port. but how can it? its ports are uni-directional - it has no way of knowing that it should issue a MIDI reset on a different port so that the input data stream on *this* port becomes parseable again. thats why many good MIDI devices have a way to do a "MIDI reset" at the user's request, precisely to deal with this kind of situation. its certainly present on my Miditemp Matrix MIDI router. i don't understand what your application is doing, but if you plan on connecting to an ongoing data stream, be prepared to reset. >That will not help my reading. The device is in sync with alsaseq and >there shuld not be needed to reset the transmitter. And even if I >do. The merge of midi streams could be smart enough to see that it is >of the same type. I don't understand any of this. "sync" and "type" have nothing to do with what is going on. You need to force the transmitting device to stop using running status for at least one message so that correct parsing can begin. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
Paul Davis wrote: > >I have a program that read's from a raw midi device. In midi there > >are some simple compression. It is assumed that if the data flow is > >correct, and the data should be interpreted as paramaters to previus > >command if it's not a new command. But when I open a raw midi stream > >I can get in to the stream without having the "previus" command. Is > >there any way to do a query or reset the stream so I can get that > >command? If it's only one midi channel sending the same type of > >command it will never get in to sync! > > raw MIDI means ***RAW*** MIDI. there is no parsing, no state, no > history, no automatic reset. you just read and write a stream of > bytes. > Yes it raw. But it's sent by the sequcenser within alsa. So the state is there. This is the configuration: Roland MCR-8->midi-device->alsa-seq->user_code->alsa-seq->raw_midi So how far back should I need to reset? The communication roland and alsa-seq is in sync and my user-land code is sending snd_seq_event_t. I guess that my problem will disapear if I turn active-sening-on and that is what I going to try. > > it sounds as if you should issue a full MIDI reset sequence when you > open the device (all notes off on every channel, reset all controllers > to a default value, restore all programs to a known state, etc.) > That will not help my reading. The device is in sync with alsaseq and there shuld not be needed to reset the transmitter. And even if I do. The merge of midi streams could be smart enough to see that it is of the same type. > > --p -- foo! ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
It's not a bug or missing feature. You're talking about opening a midi stream that is currently "running status". Unfortunately, there's no way around it. I don't think it's really possible to even guess what that previous status byte might have been. So really you can't do anything until you receive the next status byte. I think this is part of the reason why MIDI programs give 4 metronome clicks before allowing you to record. So that they can sync with the hardware. On Fri, 1 Mar 2002, Paul Davis wrote: > >I have a program that read's from a raw midi device. In midi there > >are some simple compression. It is assumed that if the data flow is > >correct, and the data should be interpreted as paramaters to previus > >command if it's not a new command. But when I open a raw midi stream > >I can get in to the stream without having the "previus" command. Is > >there any way to do a query or reset the stream so I can get that > >command? If it's only one midi channel sending the same type of > >command it will never get in to sync! > > raw MIDI means ***RAW*** MIDI. there is no parsing, no state, no > history, no automatic reset. you just read and write a stream of > bytes. > > it sounds as if you should issue a full MIDI reset sequence when you > open the device (all notes off on every channel, reset all controllers > to a default value, restore all programs to a known state, etc.) > > --p > > ___ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel > ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi bug or missed feature?
>I have a program that read's from a raw midi device. In midi there >are some simple compression. It is assumed that if the data flow is >correct, and the data should be interpreted as paramaters to previus >command if it's not a new command. But when I open a raw midi stream >I can get in to the stream without having the "previus" command. Is >there any way to do a query or reset the stream so I can get that >command? If it's only one midi channel sending the same type of >command it will never get in to sync! raw MIDI means ***RAW*** MIDI. there is no parsing, no state, no history, no automatic reset. you just read and write a stream of bytes. it sounds as if you should issue a full MIDI reset sequence when you open the device (all notes off on every channel, reset all controllers to a default value, restore all programs to a known state, etc.) --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
