When specifying the option -mididev N, pd will try the devices:
/dev/midi/MM
/dev/midi/M
in that order, where MM = N-1 with two digits and M = N-1
with one digit.
For example:
> pd -mididev 2 -verbose
[....]
device 1: tried /dev/midi01 READ/WRITE; returned -1
device 1: tried /dev/midi1 READ/WRITE; returned 5
[....]
But with -midiindev 2 and -midioutdev 2 /dev/midi will be
probed first, then /dev/midi00, then /dev/midi00, as if
N==1 instead of 2:
> pd -midiindev 2 -verbose
[...]
device 1: tried /dev/midi READONLY; returned 5
device 0: tried /dev/midi00 WRITEONLY; returned -1
device 0: tried /dev/midi0 WRITEONLY; returned -1
[...]
For -midiindev N and -midioutdev N where N > 2, pd
returns to the "normal"
/dev/midi/MM
/dev/midi/M
probe sequence.
From s_midi_oss.c (today CVS):
[...]
if (devno == 0 && fd < 0 && outdevindex >= 0)
{
sys_setalarm(1000000);
fd = open("/dev/midi", O_RDWR | O_MIDIFLAG);
[...]
if (devno == 1 && fd < 0)
{
sys_setalarm(1000000);
fd = open("/dev/midi", O_RDONLY | O_MIDIFLAG);
[...]
if (devno == 1 && fd < 0)
{
sys_setalarm(1000000);
fd = open("/dev/midi", O_WRONLY | O_MIDIFLAG);
[...]
It's clear that the above behaviour is due to the different devno == X
guards for X in { 0, 1 }.
This behaviour is not only bizarre but worst: it avoids accesing /dev/midi1
which is what I REALLY want to do (yeah, I could symlink it to /dev/midiN for
N>=2, I know). I have snd-virmidi as my second ALSA card. I connect
muse alsa seq client to virmidi 1-0 alsa seq client, which corresponds
to /dev/midi1 OSS raw midi device.
Regards,
Carlos