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
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
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.
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
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
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
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
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
Frank -
thanks for writing. I don't want to suggest for one moment that there
is any blame to be attached to the current sequencer design. None of
us knew what we know now, and as you point out the hardware state of
affairs has changed considerably.
Pentium 60 MHz (though faster iron was
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
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
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
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
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
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
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]
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
17 matches
Mail list logo