back tweaking the raspberry pi and trying to understand debian, i’m encountering weird problems …
here’s what i’ve gathered:
booting into the desktop and autostarting serialoscd and pure data via ./.config/lxsession/LXDE-pi/autostart seems to work
using crontab -e to do the same neither works in desktop nor in command-line (– is that what it’s called when you’re not booting into the desktop?). it appears that serialoscd isn’t (correctly) launched. if i try to launch it manually after approaching this route, i get a “segmentation fault” error
i have absolutely no clue about this stuff! it’s frustrating…
edit: to elaborate – in my croontab-thingy i’ve put the line
tried it with and without sleeps, tried it with various constellations of “&” – nothing seems to work. the weird thing is: if i run the script from the console manually (/home/pi/bin/script_pd), it starts and the monome is even found.
Cronjobs are executed in a special context, you should try to specify the full path of serialoscd and pd-l2ork.
Tbh i would just configure the RPi to login your user automatically (doable easily via the sudo raspi-config utility) and then call your script at then end of your .bashrc file. This ensures you that the script has all the environment variables of your user (which probably pd makes use of), i’m not sure when @reboot is executed, but it might be before every service you need is available.
I also have segfaults with serialosc on the RPi (model B) which makes it difficult for me to use confidently as a headless system.
thanks a TON for the help – was checking back here frequently
totally wasn’t aware of that, great! what is the full path of my serialosc?
i have it setup this way… i assume you mean configuring raspi-congig to log in to the non-GUI (with user “pi”)? do i understand correctly that the .bashrc file will then be run? i’m having real difficulties understanding when, at which user-level and under which circumstances (GUI / non-GUI) which particular startup-scripts/procedures etc are executed.
Hey @benniii your post got me all inspired to get my arduinome 128 running with the rpi, thanks!
I ran into the segmentation fault in serialosc too. For my setup I found two things.
Building latest serialosc source also won’t detect my arduinome on the rpi, this seems to be due to the changes @artfwo made to the linux detector in serialosc, building the serialosc source without this commit on the rpi detects the two arduinomes inside my 128 fine.
I see you’re using a 256 so it looks like the detection problems are more specific to the rpi than the device.
Once I got things detecting I was also running into a segmentation fault. On my setup this seems to be due to having two identical devices appear at the same time. I found that by editing /src/serialoscd/uv.c and adding a sleep to this function the problem went away.
dev->ready = 1;
osc_notify(self, dev, SOSC_DEVICE_CONNECTION);
fprintf(stderr, “serialosc [%s]: connected, server running on port %d\n”,
My unscientific hunch is that serialosc is not really designed to have two devices appear at the same time and it’s getting itself confused trying to connect to both at once.
What year is your 256? I’m assuming since it’s a monome it only shows up as a single device so I’m not sure if this would help in your case. Thought I’d share my findings anyway in case they’re useful.
wow, never heard about teensyduinomes (dual or not) before. you should post pictures of your grid could you also run udevadm info -a /dev/ttyACM1? it doesn’t seem to print out parent devices by default.