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

Alexander Connor a.connexx at runbox.com
Wed Sep 20 00:03:55 CEST 2017


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 at 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list