Thanks Lucas but your response suggests to me that you may have misinterpreted or misread my post. That's OK this is messy stuff

I'm not having a problem creating the 16 I/0 ports with that first command string with Linux/Alsamidi, just an issue with double parsing of the syntax I was using as both midi and filename parameters. IOhannes has provided the solution to that.

I apologize for that little aside I included at the end relating to Mac/Win as it may have clouded the Linux-specific point of the post. That's really a separate issue which will have no solution until the software midi interface between the core application and those specific OS midi platforms gets properly revamped. I've noticed some people on this list express the mistaken opinion that the midi systems on all the Pd ports are the same and "can't imagine" why they would be any different in their function or response to setup commands but I have a lot of experience that begs to differ. Miller himself started to find out a few years ago when he tried hacking Guenter Geiger's Alsamidi code in an attempt to expand port access on the other systems:

https://lists.puredata.info/pipermail/pd-list/2014-08/107646.html

My main concern with the Mac/Win versions of Pd is getting access to all midi I/O ports that exist within the internals of the PureData application. Most of the time I only use 16, but sometimes more. According to a post from Miller on this list, there's actually supposed to be 32 (to match the available audio channels I take it) but I can't get that even with Alsamidi (perhaps he was speaking in terms of using separate Pd instances, which I think I can do).

I'm not sure it's relevant and didn't even want to get into this, but to answer your question about where I am connecting those ports -- it depends. Sometimes they are sent to midi network ports (usually using QmidiNet (Linux) and IPmidi (Mac). Sometimes they are sent to one or more 16x16 midi 5 pin midi DIN hardware interfaces. As far as those DIN interfaces are concerned, the MOTU MTPAV devices I usually use have a dual dilemma when used with Pd. The hacked incomplete Linux MTPAV driver can only access the unit's midi output ports via a true hardware parallel port -- no inputs available. The Mac has full access via MOTU's proprietary USB driver, but the Mac Pd port can't even generate the ports to connect to it directly. Yes, I can use MidiPatchbay''s virtual ports (*never* IEC, that's another problem) and translation to *sort of* fudge it together, but that still brings with it more redundant programming work and the limitations I mentioned in the last post. The only way to get full 16 I/O port access from Pd to those interfaces ATM is to network midi from the Linux box to the Mac. Not really the ideal solution, especially in situations where I have to minimise redundant hardware for transport and quick setup purposes, never mind any additional latency that may be incurred.

On Tue, 19 Sep 2017 14:46:30 +0000, Lucas Cordiviola lucarda27@hotmail.com wrote:

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

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

On Tue, 19 Sep 2017 19:01:37 +0200, IOhannes m zmölnig zmoelnig@iem.at wrote:

On 09/19/2017 05:07 AM, Alexander Connor wrote:

...

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

???

where did you get that syntax from?

That comes from a combination of the vagueness of the Pd help file ("-midiindev ... -- midi in device list; e.g., "1,3" for first and third" -mididev uses same syntax) and some possibly outdated info found elsewhere that may or may not have to do with changes made to the startup flags over the course of Pd development. That info suggested that the second variable after the comma may have had something to do with designating the platform-specific midi system port number or somesuch, but with alsa it's just a single port that gets dynamically switched so it's always zero. As I said, that syntax will create 16 I/O ports, it's just that Pd also interprets everything after the "1,0" as a filename as well.

and what is wrong with $ pd -alsamidi -mididev 0,1,2,3,4,5,6,7,8,9,11,12,13,14,15 which nicely opens 16 midi in/outports, without any error?

You are correct in that that string will not produce the errors.

However, you missed the 10, so that only produces 15. Upon inserting the 10 and experimenting further I find that it actually doesn't matter what numerals you give it (they can all be zeros or anything) as long as there are 16 of them separated by commas. At least, that's the way it is with Linux and Alsa. It may be different on the other systems due to the Alsa-specific issues I touched on above. That is, different besides the fact that Mac/Win can't do more than 9 I/0 ATM anyway...

Thanks thou, at least I don't have to look at those errors any more.

gfmards IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list