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.