Thanks everyone. For anyone in the future requiring help on this: I got this working relatively easily thanks to a silly oversight - I had simply not connected the ground of the Teensy to the ground of the Raspberry Pi. I am now also powering the Teensy from the 5v of the Pi and it works well.

I have also been having some issues with stable Serial connection, and after some digging I learned that the Pi has a default Serial baud rate of 115200. That is likely faster than I need, but I couldn't figure out how to change this on the Pi (all the advice online seems to be for earlier OS versions...). So I instead changed the baud rate on the [comport] object to 115200 and it seems to work much better so far.

I'm not sure what you mean by "audio destruction" but perhaps my sound destroyer patches would be of interest https://github.com/yannseznec/soundDestroyer

I’m hoping to use serial data transmission between a Teensy and a Raspberry Pi using the Pi GPIO pins rather than a USB cable.

I have been using the [comport] object to do this previously over USB Serial, and that works (mostly) fine. However I have not yet managed to make it work by connecting the TX/RX pins between the Pi and the Teensy.

I am most likely doing something wrong, but before I dig too deep into what that might be I’m wondering if anyone has succeeded with this setup in the past, or is there some specific limitation that makes this not possible?

I'm wondering if there's any way of writing a signal to an array at something other than the current sample rate. I have always used tabwrite~ for writing signals to arrays, of course, but there does not seem to be much control over the speed of writing, you can choose a start point and then just start writing at the sample rate until you stop. Is it possible to write to the array at a slower rate?

I suspect that what I'm describing would require something like the poke~ object in max/msp, if that makes sense.

ok that is all super interesting, thanks! it seems likely a very likely culprit.

I think I will experiment with an older Pi OS to see whether it's better for Pd...do you (or does anyone else) have a suggestion for which version I should test with? I honestly can't remember which build I last used which worked reliably!

hmm I'm not sure, isn't that bug fixed in the version of Pd that I'm running? I'm on 0.51.4 when I install from the Pi repo.

another update - I've tried running the same patches on a newer model Pi. My previous issues were all on a Pi Model 3 B v1.2. I'm now running the same patches on a Pi 4 model B.

Overall it seems to run better, which is perhaps unsurprising. However I would have thought that a Model 3 would be able to generally perform decently well to play sound files and stuff.

The weird part is that while a patch is running on the newer Pi it will still often throw the "alsa xrun recovery apparently failed" error, but it doesn't seem to interrupt the sound output at all.

This seems to correlate with me starting to test things on a fresh Raspberry Pi install using the latest Raspberry Pi OS. The other funny thing that has started is that now, in order to get any sound at all, I have to specify the audio output in the command line when I launch a patch, like this

pd -nogui -alsa -audiooutdev 2 test.pd

I previously did not need to specify "alsa" or the headphone output (2).

I used to run patches on Raspberry Pi without much issue, but I am now getting really consistent crashes with the following error:

restart alsa output
alsa xrun recovery apparently failed

I can't figure out why. It seems to happen whenever I run anything even lightly intensive, but I have definitely run more complicated patches than this before. Anyone else run into this?

For anyone stumbling onto this thread, including a future version of me:

I made an extremely bare-bones but functional example that takes button inputs from Raspberry Pi GPIO pins and sends them to Pure Data, I’ve put a minimalist example up on my GitHub along with some documentation: https://github.com/yannseznec/gpioOSCpd

I think it would be pretty straightforward to do GPIO outputs too, I just don't need to right now so I didn't bother!

I'm wondering whether anyone has a reliable and up-to-date suggestion for how to use the GPIO pins on a Raspberry Pi with Pure Data?

Wiring Pi seems to be pretty much deprecated, as far as I can tell. I tried to follow this suggestion for using retrograme to generate keypresses but I couldn't get it to work: https://forum.pdpatchrepo.info/topic/11564/how-to-use-disis_gpio-for-rpi-button-input-alternatives/4

Any other options that I'm missing?

I realise I'm responding to a 5 year old post here but:

has anyone had success with using the retrogame script recently? I've installed it on a Pi and it just does not seem to convert my GPIO button press into a keyboard input. If I look at GPIO status I can see it changing when I press the button, but there is no keypress generated anywhere.

as an update to this: it's definitely because the [hid] object that is in Deken for macOS is not the same [hid] object that is on the Raspbian repo. It's confusing! I was able to make it work by copying some old screenshots I found of the old [hid] object, and having two different versions of the patch with [hid] object in action.

sorry for the double forum post, just starting a new thread for clarity.

I'm trying to use a USB joystick with pure data on my headless Raspberry Pi. I've got the patch working on my laptop just fine.

I've installed the pd-hid external on my Raspberry Pi, but the joystick doesn't do anything in the patch. The external loads when I start up Pd, but I don't get any input information from the joystick into Pd.

One theory I have is that the version of [hid] is different on the Raspberry Pi repo vs. Deken? On Raspberry Pi it is says:

[hid] 0.7, written by Hans-Christoph Steiner <hans@eds.org>
    compiled for Debian on 2022/12/07 at 09:43:35 UTC```

Whereas the version on Deken is "hidv0.1.0.dek".

Could these be different? Or is there something else entirely that I'm missing?

oh! I just found it on the Raspberry Pi repo. I used the tip on this old post to find a list of all of the available Pd repositories on the Pi repo: https://forum.pdpatchrepo.info/topic/12720/installing-externals-on-a-raspberry-pi-not-through-deken

Has anyone managed to get an HID object working on Raspberry Pi? I've tried compiling this one but haven't succeeded yet. This is the error I'm getting:

/usr/bin/ld: cannot find -lusbhid_map: No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** [/home/pi/hid-pd-external/deps/pd-lib-builder/Makefile.pdlibbuilder:885: hid.pd_linux] Error 1
make[1]: Leaving directory '/home/pi/hid-pd-external/src/hid'
make: *** [Makefile.linux:20: all] Error 2```

I have installed libhidapi and libusb as described in the Readme, so I'm a bit confused. 

It's in Deken on macOS and works great, I'd love to get it working on a Pi, if anyone has any tips!

I'm a bit late to this, but the video/patch I posted a little while ago might be useful for you

Here's a fairly standard granular patch system made in "vanilla" Pd. Enjoy!
https://github.com/yannseznec/ys.granular

and here's a video tutorial that explains the patch:

wow looks amazing! I will definitely have a play with this.

in the longer run, I feel like it would make sense for the border, background, and label to all have editable colors as well! maybe I'll stick a feature request on the main Pd code repo one day.