Hi all,

I'm try to use a bit of MIDI keyboard in PD-l2ORK on Ubuntu 16.04 at my school. I can connect perfectly through Qjackctl into [notein], but some of my colleagues are struggling with that complexity ! I was wondering if there is a better "plug and play" option using ALSA ports or OSS? {like getting a HID device to work instantly through [HID}.

I can't seem to get anything working through the ALSA ports or OSS options in PD-l2ORK.

Any help would be great

All the best

Casper

With ALSA people tend to use the "aconnect" program which essentially removes all the goodness of Pd's visual patching interface and replaces it with the most boring possible 1980 text adventure game to do the same thing.

It would probably make sense to have a "simple ALSA" option in the dropdown menu for cases like yours.

There might also be some GUI helper in Ubuntu similar to qjackctl for also midi stuff, but I haven't looked.

I get that jack can be a bit confusing for some, (myself included in the beginning,) But from my experience, doing midi stuff through alsa alone is cool for the simplest tasks, but as soon as you need to do anything more advanced like route the midi back out of pd to something else, its a bit of a nightmare. The only other way I can think of off hand that can get midi to pd without dealing with jack or alsa is through some sort of osc controller. Getting that all set up from scratch isn't exactly plug and play, but you could make an object for your collegues that does the heavy lifting so they can just load the object and control midi through the network.

Pardon If I'm behind the curve here (I'm still using L2ork v1 most of the time) but last I checked Jack Midi was not an available option in any version of Pd. You can connect through the jack midi patcher in Qjackctl (the second tab in the connections dialogue box after audio) but only if you have the jack/alsa midi bridge running. That just lets you patch jack midi only apps through to alsa midi only apps and vise-versa. I personally always use the third tab (confusingly only labeled "alsa" when it should be "alsa midi") because jack midi presently has no way to handle the larger sysex messages I deal with and blocks them by default.

Anyway the point is that If you are using any Pd variant you are always using either Alsa midi or OSS midi (actually the OSS is just an alsa-based simulator now so you're really always using alsa, but I digress). There are a few other graphical audio/midi patcher programs such as Patchage or the similar Catia program from the KXStudio package but AFAIK they all require you to set up the connections manually at least once.

However, all of those programs allow you to save your patching setup for instant automatic recall the next time you need it. In Qjackctl this is done from the "Patchbay" dialogue box. I haven't used it in awhile but if you mess with it you'll find a way to save the current set of connections. Qjackctl is pretty messy and counter-intuitive thou so for beginners you might want to have a look at the other options mentioned above.

AFAIK there's no auto-midi patching options available. I know they tried implementing something like that in Pd some time ago but they disabled it because it ended up causing more problems than it solved. There's info about that buried in the Pd list somewhere....

AFAIK there's no auto-midi patching options available.

I don't think anyone is asking for auto-patching. Just a simple way to choose an input device and output device like in Windows.

@jancsika said:

I don't think anyone is asking for auto-patching.

Well, the OP was asking for a "plug and play" option, which I would take as auto-patching a connected midi device to the first available input in Pd.

@NoDSP said:

I know they tried implementing something like that in Pd some time ago...

Just for reference, here's the Pd list thread I was referring to:

https://lists.puredata.info/pipermail/pd-list/2012-10/098642.html

Well, the OP was asking for a "plug and play" option, which I would take as auto-patching a connected midi device to the first available input in Pd.

Ah, you're right.

Still, I have a feeling choosing devices from a dropdown menu-- as happens in the MIDI prefs on Windows-- would be sufficiently simple in this case.

@jancsika That's not a bad idea in principal -- some of the other linux midi apps give you the option of patching both externally and from a patching routine internal to the app -- but beware. A lot of the time I notice those internal patch routines either don't work properly or cause conflicts/screw-ups with the external patch apps in situations where you find you have to use both. I don't know if it's because of improper coding of the internal patch routines or a limitation of the Alsa midi system, but It's for that reason I always use the external option with all my linux midi apps.

I'm just trying to say that all the midi patching stuff may be more complicated than it seems on the surface. The Mac and Windows Pd Vanilla midi dialogues are supposed to work that way but I can tell you they are definitely broken; not just because of the limited 9 port access (it's currently 4 in L2ork?) but because something isn't right (or completely absent) in the whole port multiplexing scheme. I've never been able to connect those 9 ports past the first 9 midi ports on the Mac's system list. You can test this with any application that will create virtual midi ports, network midi ports etc.

@NoDSP Yea, you are right, actually. The a2j bridge is what enables jack patching for midi in most programs. I suppose that's an important detail that I overlooked. Once a2j is up and running, it feels like part of jack, but yea technically it is alsa. Your also right in that Ive noticed mixing internal and external patching of inputs and outputs to be problematic. I think it's some kind of permissions conflict... Like each program wants to take ownership of the patching privelages and they block eachother out. Im still looking for a way to resolve that...

@casper I was thinking a bit about it, and you might check out the jackx library of externals. There is an object in there that lets you manipulate jack patching from within PD. for instance, my sound card is a bit weird, as the main outputs read as output 3 and 4 instead of 1 and 2. When pulseaudio connects to 1 and 2 on startup, theres no sound. So each time i'd restart, I would have to manually open some patching program (I prefer carla from kxstudio,) and route everything correctly. Eventually, I made a patch that uses jack-connect from jackx to automatically route everything properly via loadbang. I made another version of it that starts, connects everything and then closes itself. I put that in my startup applications, so now every time I reboot, everything is automatically routed properly. You could make an object like that for your colleagues so when they open up pd, the midi routing is right there for them. I'll let you take a look at the patch I made to do this. (note, open pd with the -noloadbang flag or the patch will open and close all instances of pd-l2ork in 10 seconds.) also, the ports that you will be connecting will likely have different names then the ones here, so adjust them accordingly, and finally make sure the jackx externals are loaded and working properly to make this work. jackconnect.pd

Thanks to everyone for the info

@th8a thanks for this object that's a great idea. I've checked both /usr/lib/pd-l2ork and /usr/lib/pd/extra and neither locations on my harddrive contain the jackx library. I've also searched the net; I get the jackx release page to find that there are no current releases!

https://puredata.info/downloads/jackx

@th8a could you possibly share the two jackx library objects [jack-connect] and [jack-ports] with me please so I can re-work your patch ?

Patchage is the answer for me!

Sure. I think I found my copy of jackx by compiling it from source out of the pd-l2ork svn repository. Here is a build that I did on my intel x86_64 architecture in Ubuntu.. If your on similar hardware and a linux distro, they should work fine jackx.zip

If jackx wont work for some reason, you can also acheive similar results sending jack scripts through the shell object