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). _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
