29 Mar
2009
29 Mar
'09
5:11 p.m.
Hi,
I am stuck in a problem with MIDI merging.
I am currently using two external MIDI devices that connect to my notebook via
an external USB MIDI adaptor (a nice Edirol UM2).
One of these devices transmits data in running status, which means it omits
the status byte of NOTE ON messages if many NOTE ON messages are transmitted
and there is no change of the channel.
The second device transmits data in the ordinary uncompressed mode and never
leaves out the status byte.
Now I need to route these external MIDI devices to a MIDI application.
The devices show up in my notebook as physical ports UM2-1 and UM2-2 and what
I do is to simply connect these ports to the IN port of the MIDI application.
And now there is a problem: as I have connected the two devices to the IN port
the application (or the driver of the MIDI port) has to do MIDI merging. But
something is wrong with the merging, if the running status device's data
bytes have to be merged with the second device's data stream.
The application detects that there is the status byte missing in the complete
data stream that it is receiving and it does not "resync" even if the running
state device transmits a status byte because the channel has changed. So the
application indicates an error message stating there is a missing status byte
and that it only got data bytes.
1.) Which part is actually responsible for the MIDI merging of two or more
output devices into one input device? Is it the driver of the port or is it
the application, that is in the end receiving the MIDI data stream?
2.) Is it illegal to connect two output devices to one input port?
3.) If I should need some kind of virtual MIDI multiplexing/demultiplexing
driver: which one should I chose? I have debian and would like to install
from repository.
Thanks for any hint and kind regards,
Crypto.
1 Apr
1 Apr
8:32 a.m.
Crypto wrote:
I am currently using two external MIDI devices that
connect to my notebook via
an external USB MIDI adaptor (a nice Edirol UM2).
[...]
And now there is a problem: as I have connected the two devices to the IN port
the application (or the driver of the MIDI port) has to do MIDI merging. But
something is wrong with the merging, if the running status device's data
bytes have to be merged with the second device's data stream.
Please note that neither the USB MIDI protocol nor ALSA's sequencer
messages can use running status.
That IN port is an ALSA sequencer port, isn't it?
Does the data look correct when you view it with aseqdump?
1.) Which part is actually responsible for the MIDI
merging of two or more
output devices into one input device? Is it the driver of the port or is it
the application, that is in the end receiving the MIDI data stream?
Each ALSA sequencer input port has a queue of messages; ALSA
automatically puts messages into this queue in the correct order.
2.) Is it illegal to connect two output devices to one
input port?
No.
3.) If I should need some kind of virtual MIDI
multiplexing/demultiplexing
driver: which one should I chose?
Connecting one port to several other ports works without a separate
device.
In certain situations, you might want to use the MIDI Through device.
Best regards,
Clemens
12:19 p.m.
On Wed, Apr 1, 2009 at 3:32 AM, Clemens Ladisch <cladisch(a)fastmail.net> wrote:
Crypto wrote:
If I understand correctly, running status is not an alternative to the
MIDI protocol, it is an alternative way of interpreting the bytes
(comparable to nrpn or such), so there should be no issue of MIDI or
ALSA incompatibility. I think what he is looking for is a program that
will convert from running status to the standard format, and for that,
all you need is a program that can read the raw midi bytes and
interpret them properly. I think this could be fixed in PD with a half
hour or so of patching, perhaps midish could do it as well. Please
correct me if I am wrong about this.
I am currently using two external MIDI devices
that connect to my notebook via
an external USB MIDI adaptor (a nice Edirol UM2).
[...]
And now there is a problem: as I have connected the two devices to the IN port
the application (or the driver of the MIDI port) has to do MIDI merging. But
something is wrong with the merging, if the running status device's data
bytes have to be merged with the second device's data stream.
Please note that neither the USB MIDI protocol nor ALSA's sequencer
messages can use running status.
That IN port is an ALSA sequencer port, isn't it?
Does the data look correct when you view it with aseqdump?
I think when he is talking about multiplexing, he is talking about
being able to mix midi streams that are using running status, so the
PD or midish process would act as the "multiplexer".
1.) Which part is actually responsible for the
MIDI merging of two or more
output devices into one input device? Is it the driver of the port or is it
the application, that is in the end receiving the MIDI data stream?
Each ALSA sequencer input port has a queue of messages; ALSA
automatically puts messages into this queue in the correct order.
2.) Is it illegal to connect two output devices
to one input port?
No.
3.) If I should need some kind of virtual MIDI
multiplexing/demultiplexing
driver: which one should I chose?
Connecting one port to several other ports works without a separate
device.
In certain situations, you might want to use the MIDI Through device.
Best regards,
Clemens
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
3:46 p.m.
Justin Smith wrote:
On Wed, Apr 1, 2009 at 3:32 AM, Clemens Ladisch
<cladisch(a)fastmail.net> wrote:
It is a part of the MIDI protocol.
Please note that neither the USB MIDI protocol
nor ALSA's sequencer
messages can use running status.
If I understand correctly, running status is not an alternative to the
MIDI protocol, it is an alternative way of interpreting the bytes
(comparable to
nrpn or such), so there should be no issue of MIDI or ALSA
incompatibility.
Running status is a feature of the encoding used by MIDI.
USB MIDI and the ALSA sequencer use different encodings.
A USB MIDI adapter converts from MIDI to the USB MIDI protocol, and the
USB MIDI driver converts that data back to MIDI. It is not possible to
detect from the result whether the original MIDI data used running
status.
Best regards,
Clemens
6:10 p.m.
On Wednesday 01 April 2009 at 19:46:30 Clemens Ladisch wrote:
It is a part of the MIDI protocol.
Sorry, I do not get it.
I have checked the ports using aseqdump connecting to the two UM2 ports of the
external USB MIDI interface.
aseqdump did not report any error message, so I think I can assume that at
this connection there is no problem running status vs. normal status.
I connected the two UM2 ports to the MIDI Thru port and checked to see if
merging works, got no error messages from aseqdump either. I checked this
both UM2 connectors at a time, then both merged into one output.
I am also not sure if I got the USB MIDI part correctly: what I have is an
external USB device that offers two IN/OUT ports having standard 5 pin DIN
connectors each to connect to other standard MIDI devices. So this device is
not transferring USB MIDI data - it is imho simply converting ordinary MIDI
data into USB data without further manipulation, then inside the notebook
ALSA applications see the UM2 connectors as a standard MIDI hardware port
each.
So the hardware ports that I see denoted as UM2 have got to be ALSA sequencer
ports.
I have never had any issues related to running status vs. normal status before
until I wanted to use keykit to work on incoming MIDI data. This is where I
cannot find what causes the error.
I suspect it is keykit that needs more than one IN port and it is keykit which
cannot merge two different MIDI streams that come in at its IN port - but I
am not yet 101% sure about that. So in contrast to what is normally possible
(connect more than one OUT port to one IN port) keykit cannot do this.
Kind regards,
Crypto.
Justin Smith wrote:
> On Wed, Apr 1, 2009 at 3:32 AM, Clemens Ladisch <cladisch(a)fastmail.net>
wrote:
Please note that neither the USB MIDI protocol nor
ALSA's sequencer
messages can use running status.
If I understand correctly, running status is not an alternative to the
MIDI protocol, it is an alternative way of interpreting the
bytes (comparable to
nrpn or such), so there should be no issue of MIDI or ALSA
incompatibility.
Running status is a feature of the encoding used by MIDI.
USB MIDI and the ALSA sequencer use different encodings.
A USB MIDI adapter converts from MIDI to the USB MIDI protocol, and the
USB MIDI driver converts that data back to MIDI. It is not possible to
detect from the result whether the original MIDI data used running
status.
2 Apr
2 Apr
1:52 p.m.
Crypto wrote:
I am also not sure if I got the USB MIDI part
correctly: what I have is an
external USB device that offers two IN/OUT ports having standard 5 pin DIN
connectors each to connect to other standard MIDI devices. So this device is
not transferring USB MIDI data - it is imho simply converting ordinary MIDI
data into USB data without further manipulation,
That "USB data" *is* USB MIDI data; the USB device has to convert from
the MIDI encoding to the USB MIDI encoding.
then inside the notebook ALSA applications see the UM2
connectors as a
standard MIDI hardware port each.
Yes, because the driver converts the data back.
So the hardware ports that I see denoted as UM2 have
got to be ALSA sequencer
ports.
Yes. Actually, there are also raw MIDI ports for OSS applications.
Does KeyKit have ports that are listed by "aplaymidi -l" (ALSA sequencer
ports), or does it want to read from devices named /dev/midi* (OSS ports)?
Best regards,
Clemens
3:58 p.m.
On Thursday 02 April 2009 at 17:52:35 Clemens Ladisch wrote:
Does KeyKit have ports that are listed by
"aplaymidi -l" (ALSA sequencer
ports), or does it want to read from devices named /dev/midi* (OSS ports)?
Best regards,
Clemens
Clemens,
there are two ways keykit can handle its ports and both need different
settings when compiling the sources. I thought I had compiled keykit to use
ALSA sequencer ports but aplaymidi -l indeed does not list keykit's ports. So
I guess they must be OSS ports and ALSA is wrapping them invisibly for me.
aconnectgui shows keykit ports so I have never suspected anything.
I have never intended to use anything different than ALSA sequencer MIDI
connection and I am not sure how it all happened I have not gotten that for
keykit.
Now I am trying to recompile keykit so it can connect to ALSA sequencer ports
and have more than one IN and OUT port, and, hopefully, supports incoming
running status.
Kind regards,
Crypto.
11:23 p.m.
On Thu, Apr 2, 2009 at 1:58 PM, Crypto <crptdngl71(a)gmx.net> wrote:
On Thursday 02 April 2009 at 17:52:35 Clemens Ladisch
wrote:
I wrote the code in keykit to support the ALSA MIDI sequencer. its
there. i haven't used keykit in a while and i don't have it installed
on any of my systems right now, so i can't tell you how to use it.
Does KeyKit have ports that are listed by
"aplaymidi -l" (ALSA sequencer
ports), or does it want to read from devices named /dev/midi* (OSS ports)?
Best regards,
Clemens
Clemens,
there are two ways keykit can handle its ports and both need different
settings when compiling the sources. I thought I had compiled keykit to use
ALSA sequencer ports but aplaymidi -l indeed does not list keykit's ports. So
I guess they must be OSS ports and ALSA is wrapping them invisibly for me.
aconnectgui shows keykit ports so I have never suspected anything.
I have never intended to use anything different than ALSA sequencer MIDI
connection and I am not sure how it all happened I have not gotten that for
keykit.
Now I am trying to recompile keykit so it can connect to ALSA sequencer ports
and have more than one IN and OUT port, and, hopefully, supports incoming
running status.
5508
days inactive
5513
days old
linux-audio-user@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Clemens Ladisch -
Crypto -
Justin Smith -
Paul Davis