Great thanks-- I'm going to type out and share my process here in case anyone else is curious or has similar issues in the future.

I've gotten a Raspberry Pi 4 Model B to read distance in cm from this script here (https://tutorials-raspberrypi.com/raspberry-pi-ultrasonic-sensor-hc-sr04/)--

At this point I am going to try my hand at converting this script into a PureData object. After that I will try to use those values as an amplitude variable to send out to [dac~]. One foreseeable issue is that there are pretty dramatic value spikes in the python code when you move an object in front of the sensor (e.g. it will read 30cm, 1207cm, 11cm).

I'll report back later after a bit more digging.

** mini-update

I had to reset to RaspberryPi OS and manually install puredata extended 0.43.4 using this guide here (https://puredata.info/docs/faq/debian). From there I managed to get the cyclone extension to work but not py4pd--trying to figure out a workaround.

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).

@oid thanks this is great stuff.

I managed to create a log file and write data to it through your logger.pd abstraction but I had to disable the part that starts pdreceive and start pdreceive from Terminal manually. Obviously pdreceive and many other commands on my system is not working global:

/Applications/Pd-0.53-2.app/Contents/Resources/bin/pdreceive 3000 >> mylogfile.txt

...and that is because something is up with my system/shell.

~ % pdreceive 3000 >> mynewlogfile.txt
zsh: command not found: pdreceive

Working on this I use macOS Monterey 12.6.9 and by default zsh(z-shell) is used. I tried to change to using bash but it is the same problem still.

Before I dive into this and try to fix it I would like to ask you

1. if your logger.pd abstraction did work on your system
2. what os do you use?
3. for advice on how to set up my computer in this senario:

I see many uses for me with this setup but the goal at the moment:

is to put this on a raspberry pi and record interaction sessions with an artwork during the day, and optionally process it during the night. It will be open for interaction for a month, not monitored.

But when coding I use my mac. So ideally I want to set up my mac as similar as possible to the raspberry pi having to make as few changes as possible when switching computer.

Any idea on how to fix this without messing up my mac? And where is a good starting point to get some better understanding of shell(s)? So I do not bloat this thread/forum with non-pd questions.

Thank you so much, I really appreciate it.

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

@Dizzy-Dizzy If it is hardware/os related then first you could try editing boot/cmdline.txt..... adding
dwc_otg.speed=1
which will limit USB to usb1.1 which should be enough for your soundcard (if it is 1.1 compatible) and should help reduce processor interrupts. It will slow everything connected via usb to the rpi.

You could also look at this...... https://baheyeldin.com/linux/how-fix-audio-skips-and-stuttering-raspberry-pi.html although I cannot be sure that it is relevant.
You would need to change "2708" for your sound card, and maybe add enable_lim=1 as in the second (actually older) thread linked below.
It seems strange however that USB and dma problems would still be occurring so long after this....... https://forums.raspberrypi.com/viewtopic.php?t=12097&sid=85de7813bf992de7630f59d96905a0e0&start=425 ..... I would expect them to be fixed by now.

But it doesn't sound to me like a glitch in the sense that the RPI is unable to process the audio.
It might be something in your patch causing it..... and it sounds like a command is forcing a re-read of a wav file numerous times between 3 and 4 seconds.
You have bangs on almost all the controls.
Are any of them sticking on while the "glitch" occurs?
It is unusual I think to capture a bang in a screenshot...... and we can see one of them "on" in your post.
You could put a [print] at places in your patch to see whether you have a stream of messages between 3 and 4 seconds where you expected only one message.

But you say you have intensively investigated the patch so I am probably wrong and I cannot see in your patch what it could be.

Running it on another computer would be the quickest way to eliminate the patch as the source of the problem..... or not.....
David.

it gets in the weeds - basically you got a problem if your knob isn't a digital encoder which sends things like +1 or -1 to move numbers - typically these also have a push button.

if your knob is a potentiometer/slider/knob/pot like on an electric guitar - these only give discrete values and will Jump like on the left.

if you use one of those like I am on the right - and I apologize for it seeming messy, I'm cleaning up little problems - but the knob is still a potentiometer, so even tho I changed it into something that compares if its going higher or lower it ends up at weird places - so to do it right these needs to be an encoder type of knob - (which I'm simulating by just hitting the 1 and -1, a little surprised acting like an encoder isn't in [knob] yet.)knob-problems-pot-vs-encoder.pd

Hi everyone!

I'm a complete novice when it comes to Raspberry Pi, PureData, Python, and this whole world of electronics in general so I could really use some help with this project I'm working on.

Basically what I'd like to do is send numerical values from an environmental sensor HAT on the Raspberry Pi GPIO pins to PureData in real-time to control effects autonymously. This would all be on the same Raspberry Pi. I've heard Python may work as a good communicator between the hardware sensors and PureData, so I'm just wondering if other people have successfully managed to create a functional real-time data stream from the GPIO pins into PureData.

Any help would be much appreciated, thank you!

@Coalman
To give you even more options:

If you want to patch everything in PD but no hardware change, you could connect an old laptop, or Bela (Beagle Board) or Pi and Arduino via USB (as virtual serial port) and use Firmata or PDuino (available in Deken) to access Arduino's GPIOs from PD.
Not sure if this is the case for the async PWM. (But you could add that function as exception on the Arduino side with input from serial.)

What speed is the PWM? Higher than audio Niquist (probably yes)?
Else you could just do PWM in PD.

Most, if not all popular (micro)controllers provide asynchronous PWM-pins today. Read the datasheets.

Did you already search your answers?
https://forum.bela.io/d/1009-basic-pwm-question/
https://forum.pdpatchrepo.info/topic/12112/raspberry-pi-gpio-and-puredata-does-it-work/
https://github.com/owenosborn/rpi_gpio

There should be many examples for, PD <-> GPIOs on Bela, as this is what it's all about.

reason for this inefficiency is that my knowledge is fairly limited on these platforms.

Maybe decide for one board (or an old laptop with comport) for all projects, and grow with it.

hello! this question intersects with Pd even if it is not about Pd specifically...
I currently have several (installation) pieces in which the sound is run from Pd and then I have motors or sensors being run off other things.
This means that in one case I am using a raspberry pi for the Pd part and an Arduino mega for the motor part
In another case I have Pd running on a Bela/BBB and then an Arduino doing the motor stuff.

The reason for this inefficiency is that my knowledge is fairly limited on these platforms. However, it is annoying to have to use the extra gear when I don't have to. Especially because I know that both the raspberry and the Bela have pins that could be used in place of the arduino for this purpose. Since the Bela is a simpler case and the pins can be addressed directly from Pure Data, I will ask about that and leave the Raspberry behind for now (as I think I would end up running Pd AND Arduino on that board anyway, whereas with Bela, one can easily address the pins from inside Pd without any other programs or libraries).

My question is this: does anyone know how the standard mappings of pins Analog/Digital/and PWM pins on the Arduino lines up on the Bela? Does the Bela have have PWM pins like, for example pins 8,9, 10,11 on Arduino Mega or Dueminanove? And if so, what is the best way to address them from Pure Data? Basically, I'd like to convert my already very simple Arduino sketches over to Pd, so that both motors and Audio can run from the same patch.

I know this isn't specifically a Pd issue but I have asked a related question on the Bela forum but didn't get an answer so I hoped someone might know or be able to suggest a resource over here...
I have traversed the Bela documentation already of course....and will continue with that meanwhile.

Jorge