[PD] Bug: Double parsing of -mididev startup parameters in Linux

[Alexander Connor]

Submitting for comments here before I send it to the bug tracker.


File this Linux bug under minor-but-annoying.

I use a desktop launcher to set up a midi-only Pd instance with a 16x16 input/output buss.  The following startup string will do this successfully:

pd -rt -noaudio -audiobuf 1 -sleepgrain 0.5 -alsamidi -mididev 1,0 2,0 3,0 4,0 5,0 6,0 7,0 8,0 9,0 10,0 11,0 12,0 13,0 14,0 15,0 16,0

However, all of the the -mididev parameters past the first specified are interpreted both as -mididev parameters and as filenames for Pd to open on startup.  This results in a string of 15 "can't open" errors (unless I suppose there are a set of available Pd files with those names) followed by "Opened Alsa Client 130 in:16 out:16" in the main window, like so:

2,0: can't open
3,0: can't open
4,0: can't open
5,0: can't open
6,0: can't open
7,0: can't open
8,0: can't open
9,0: can't open
10,0: can't open
11,0: can't open
12,0: can't open
13,0: can't open
14,0: can't open
15,0: can't open
16,0: can't open
Opened Alsa Client 130 in:16 out:16


Here's the interesting part (at least for me): It is possible to reduce the number of error reports by redundantly inserting the -mididev flag in front of each discreet -mididev parameter up to the ninth port.  So the startup string:

pd -rt -noaudio -audiobuf 1 -sleepgrain 0.5 -alsamidi -mididev 1,0 -mididev 2,0 -mididev 3,0 -mididev 4,0 -mididev 5,0 -mididev 6,0 -mididev 7,0 -mididev 8,0 -mididev 9,0 10,0 11,0 12,0 13,0 14,0 15,0 16,0

will produce the following Pd console report:

10,0: can't open
11,0: can't open
12,0: can't open
13,0: can't open
14,0: can't open
15,0: can't open
16,0: can't open
Opened Alsa Client 130 in:16 out:16

However, If you use this method past the ninth port, you start to lose ports:

pd -rt -noaudio -audiobuf 1 -sleepgrain 0.5 -alsamidi -mididev 1,0 -mididev 2,0 -mididev 3,0 -mididev 4,0 -mididev 5,0 -mididev 6,0 -mididev 7,0 -mididev 8,0 -mididev 9,0 -mididev 10,0 11,0 12,0 13,0 14,0 15,0 16,0

produces:

11,0: can't open
12,0: can't open
13,0: can't open
14,0: can't open
15,0: can't open
16,0: can't open
Opened Alsa Client 130 in:14 out:14

on up, until you get to:

pd -rt -noaudio -audiobuf 1 -sleepgrain 0.5 -alsamidi -mididev 1,0 -mididev 2,0 -mididev 3,0 -mididev 4,0 -mididev 5,0 -mididev 6,0 -mididev 7,0 -mididev 8,0 -mididev 9,0 -mididev 10,0 -mididev 11,0 -mididev 12,0 -mididev 13,0 -mididev 14,0 -mididev 15,0 -mididev 16,0

which produces no errors, but leaves you with:

Opened Alsa Client 130 in:2 out:2

The reason I find that interesting is because -- in my experience -- it would appear to be the only (partial) Linux manifestation of the current 9 midi port limitation which so greatly, vastly and deeply disappoints me about the Macintosh and Windows ports of PureData (and BTW no, going through a tedious sequential startup process of making sure the first 9 ports on the system list are the the correct set of virtuals I have to create, using redundant extra-jitter-inducing 3rd party routing/translation apps and hoping and praying it will work on the first try [fails often] doesn't cut it as a reliable workaround for my purposes, especially when I'm trying to make a cross-platform patch with multiple devices that use port-wide messages that can't be confined to a single midi channel).