Pisound software possibly breaking MIDI input?


Hi. I’m trying to use some customised MIDI controllers built with Teensy to control PD patches on my Raspberry Pi. After lots of troubleshooting I’ve narrowed down some issues and I’m wondering whether whether the Pisound is causing some trouble.

Currently trying this with Raspbian Jessie Lite and PD 0.46, but the same thing was happening with Stretch Lite and PD 0.47.

Here are my symptoms:

  • If I run a PD patch that uses USB MIDI input before I install the Pisound it works fine. I do this by plugging in my Teensy via USB and launching the patch with pd -nogui -midiindev 1 miditest.pd

  • If I install the Pisound software (using the curl command as described here the MIDI input no longer works. As part of this install it asks me to upgrade the kernel.

  • With the Pisound software installed, the rPi still sees the MIDI controller, but PD does not, no matter what startup flags I use. Since doing that I can’t seem to get any MIDI input in PD, no matter what startup flags I use. Most tellingly, if I run pd -nogui -listdev (without the Pisound plugged in) I get the following list:

audio input devices:
bcm2835 ALSA (hardware)
bcm2835 ALSA (plug-in)
Teensy MIDI (hardware)
Teensy MIDI (plug-in)
audio output devices:
bcm2835 ALSA (hardware)
bcm2835 ALSA (plug-in)
Teensy MIDI (hardware)
Teensy MIDI (plug-in)
API number 1
no midi input devices found
no midi output devices found

I find it very odd that it lists my Teensy MIDI device as an audio input and output, and also says that no midi input or output devices have been found. If I have the Pisound plugged in then it is listed as and audio device (in and out) but it still says no midi devices are found. It is somewhat understandable that my patches will not therefore recognise any midi activity, but I don’t understand why PD isn’t seeing the MIDI devices after installing Pisound.

If I run aconnect -o I can see that the Raspberry Pi recognises the device:
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘Teensy MIDI’ [type=kernel,card=1]
0 ‘Teensy MIDI MIDI 1’

and if I run aseqdump -p 20 the MIDI data comes streaming through normally. I’m interpreting this to mean that the MIDI device is working, and the alsamidi system is working on the rPi. However something is stopping it from being recognised by PD.

Any ideas? Thanks!



Hi, ALSA MIDI works by software creating virtual input and output ports which have to be hooked up with external hardware ports using aconnect command.

When you start Pure Data via the button or the Pisound App, it attempts to connect all the inputs it finds to the Pure Data’s virtual output MIDI port, and MIDI outputs to PD input.

If you launch PD manually, you have to make the connections manually, using aconnect or aconnectgui.

Here’s how Pisound launch scripts attempts to connect everything it finds:



ok interesting! I thought I had done it this way before but I’m obviously mistaken. so I can initially test it by launching the patch with the Pisound button - that should automatically make my MIDI control objects work in Pure Data?

My main learning so far is how little I know about how MIDI works in pure data :slight_smile:



Launching via the button will connect all MIDI ins and outs to PD process.

It’s not specific to Pure Data, this is how MIDI is implemented in Linux, other OSes have different implementations. An advantage of Linux implementation is that multiple processes can use the same MIDI device at an expense of additional setup steps required, while on Windows, software gets exclusive access to selected MIDI devices so they can’t be shared with multiple applications easily.



awesome, thanks! I’ll give it a try. do you have any tips for using aconnect to make the connections manually, in case I need to do that?



In case of making the connections ‘by hand’, I suggest using aconnectgui (do sudo apt-get install aconnectgui if the system says it’s not found), if you plan to script it, use aconnect xx:x yy:y (replace x and y with the numbers you see after running aconnect -l) to make the intended virtual connection ‘from x to y’.