Hi all,

I've built 3 small Pd patches to fit in my workflow, e.g. to convert one MIDI controller's messages into OSC, one to light up the LEDs of another controller, one to control a pedal, etc.

If I open 2 instances of Pd, each with its own MIDI (or audio, for that matter) inputs and outputs, Alsa-Midi refers to them as follows:

$ aconnect -l
client 128: 'Pure Data' [type=user,pid=260121]
    0 'Pure Data Midi-In 1'
    1 'Pure Data Midi-Out 1'
client 129: 'Pure Data' [type=user,pid=260548]
    0 'Pure Data Midi-In 1'
    1 'Pure Data Midi-Out 1'
    2 'Pure Data Midi-Out 2'

The client name is the same, and the client ID cannot be predicted - depending on which controllers I have plugged in and in which order, it might be any number incremented from 128. The tools that should remember and restore the patching (jack_patch, Ray Session and the like) struggle the same as I do to figure out which instance of Pd to connect to which controllers.
I want to keep these patches in separate PD instances so I can mix and match, and not necessarily have all of them open, and always rely on the specific instance's MIDI input number and output number.

So, here's my question: any idea if it is possible to rename Pd's alsa-midi ports? I found surprisingly little online about this issue, yet I can't really believe that nobody met this issue before...

I've never seen the command line option -jackname to actually have an effect, but in any case Pd does not use Jack MIDI as far as I understand.
I've been thinking about running the patch in a libpd wrapper instead, e.g. from a Python script in which I could specify the client's and port names, but I'm struggling a bit to install pylibpd.

@zigmhount I generally just pay attention to the order I start them in and specify the midi stuff at startup, pd -alsamidi -mididev 1 <files to open> first listed by aconnect will be the first started. The entire startup process including connecting the midi ports can be scripted so all you have to do is run a script and have everything good to go. I will try and get around to making my pd script a more generic startup/connect script if you want, probably can do it tomorrow. But perhaps someone knows a way to name them or has a better alternative. I just went with what I know when I made my script, more interested in making it all work then figuring out the best way.

@zigmhount If a devicename is reported in the Pd midisettings dialog (I would expect that to be the case) then you can choose the midi ports to use for each Pd instance within a patch instead....... https://forum.pdpatchrepo.info/topic/13217/save-and-recall-midi-settings-in-a-project
This one seems a little easier to use........ set_midi-order.pd
If there are spaces in the names you can convert the whole name to a symbol that contains spaces with this.... concat.zip
David.

Thanks both,
@oid I have indeed used scripts before, calling aconnect to list, extract the name of the client/port I need to connect to Pd, and connect it to Pd's inputs and outputs. However in the current case I'd like very much something more modular to connect in a patchbay.
@whale-av thanks, I didn't know about the mediasettings external, this will probably useful in the future. Similar to @oid's suggestion though, this is also about connecting Pd with other MIDI clients from within the Pd patch.

I'll continue exploring the libpd route, but I'll have to learn a bit more about Python's modules management to figure out how to properly install and use it.
Or maybe open the patch in plugdata inside a plugin host...

@zigmhount said:

Pd with other MIDI clients from within the Pd patch.

I missed that, in that case I think I would just do it all in pd. Script to start pd instances so they are in known order (if needed) and then use [command] to get the port numbers and place them in suitably named [v ]s. Make your midi router a patch and then send your alsa commands out through [command].

I've progressed with libpd instead :D
I know that this will probably make things more difficult with complicated patches and externals (I would have to compile libpd with support for these externals if I understand correctly), but for simple patches it seems pretty straightforward. I haven't tested it properly yet, but this small script exposes virtual ALSA-MIDI ports in a patchbay (which I can connect to anything) and just forwards notes and CCs to Pd, and receives Pd's notes and CC back and forwards it out to ALSA:

import mido
# install python-rtmidi from pip
from functools import partial

from pylibpd import *

my_client_name='My Libpd Client'
input_port_name='Input'
output_port_name='Output'

# Open Input and Output ports (Rtmidi)
# Creating multiple virtual ports will create multiple clients with the same name.
outport = mido.open_output(output_port_name,virtual=True,client_name=my_client_name)
inport = mido.open_input(name=input_port_name,virtual=True,client_name=my_client_name)

def pd_receive(*s):
    print('Printed by pd:', s)

def midi_out(*s):
    match s[0]:
        case 'note':
            if s[3] > 0:
                m=mido.Message('note_on', channel=s[1], note=s[2], velocity=s[3])
            else:
                m=mido.Message('note_off', channel=s[1], note=s[2], velocity=s[3])
        case 'cc':
            m.mido.Message('control_change', channel=s[1], control=s[2], value=s[3])
    
    outport.send(m)

# Callbacks to receive messages from Pd:
libpd_set_print_callback(pd_receive)
libpd_set_midibyte_callback(pd_receive)
libpd_set_noteon_callback(partial(midi_out,'note'))
libpd_set_controlchange_callback(partial(midi_out,'cc'))

libpd_open_patch('midi_processing.pd','.')

with inport:
    for msg in inport:
        match msg.type:
            case 'note_on':
                libpd_noteon(msg.channel,msg.note,msg.velocity)
            case 'note_off':
                libpd_noteon(msg.channel,msg.note,0)
            case 'control_change':
                libpd_controlchange(msg.channel,msg.controller,msg.value)
            case 'sysex':
                libpd_sysrealtime(1,msg.byte)

libpd_release()

And that's it! It's quick & dirty and it will get more complicated if I need to handle any type of MIDI messages, but notes and CCs should do for now.
Looks like this in the patchbay:

I use Pd with Jack.
I use the QjackCtl patchbay to make sure Pd connects it's MIDI ins/outs and load that on QjackCtl startup automatically.

The patchbay can use regular expressions to instantiate connections, you just need to be careful about the "many-to-many" type of situations.