[PD] oss midi inconsistent behaviour (bug?)

[Carlos Pita]

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