Re: Rawmidi bug or missed feature?

[Peter Enderborg <pme@ufh.se>]

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
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel