Ok, dont send it to a bug tracker yet.
Do you have gear that counts 32 (5 pin DIN connector) for 16 MIDI-in /16 MIDI-out? I mean you can plug 32 midi cables in it?
Or you have 1 soundcard with 2 midi plugs (the normal in / out)?
To avoid confusion keep in mind that 1 midi plug has 16 channels in it.
Mensaje telepatico asistido por maquinas.
On 9/19/2017 12:07 AM, Alexander Connor wrote:
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).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list