Launching a default pd patch in headless mode

Hi all,

I just started with patchbox a few days ago and so far it’s been great! I’ve gotten pd talking with an arduino over usb serial and outputting multichannel audio on a cheapo 5.1 usb sound card on a RPI4 (w/o a PiSound) in console mode. I just have a couple of questions about about headless operation, and unfortunately, I don’t have access to the installation I’m working on at the moment, so I figured I’d ask here in the hopes that it will save me some time tomorrow…

  1. My goal is totally independent headless operation. At the moment I have to run pd /home/patch/Pd/MAIN_PATCH_01.pd * to launch my patch (although I’m not sure that the * is really necessary, as it doesn’t unblock the terminal as I thought it would… EDIT: it looks as though I was confusing * with &, so I’ll give that a try tomorrow). It seems as though I should enable the pure data module and edit something in the puredata/launch.sh script but, I’m not sure exactly what - do I have to replace the $PATCH in quotes on line 26?

  2. I’ve read that it’s not great to just yank the power from a RPI (although I have done that for a previous installation using CCRMA’s satellite build without any problems). Given that I want this to work as simply as possible, I figured that perhaps I should attach a button to the arduino, and after a long press send a signal over to pd and tell it to shutdown the Pi by passing sudo shutdown -h now to the [shell] (assuming that’s available in the vanilla version). Does that sound reasonable, or is there perhaps some more graceful builtin way of managing this?

Thanks in advance for you help!

Cheers,
-eric

Yes, the & is the one to run something in background.

On activating the Pure Data module through patchbox utility, it will ask which patch it should autolaunch, it looks for patches in /usr/local/puredata-patches. In partiuclar it looks for blokas.yml metadata files, or just for plain main.pd file. For example, your patch entry point could be located here: /usr/local/puredata-patches/mypatch/main.pd

sudo shutdown -h now is fine for safely shutting down the system. Otherwise, as you know, you may end up with a corrupted file system and it unable to boot again. Also, always disconnect from the power outlet side first, and wait until the LEDs turn off - I’ve had a bit damaged micro usb port on one Raspberry Pi which was very noisy during disconnecting, so even with proper system shutdown, it ended up corrupting the SD card a couple of times.

Thanks so much, this is such a cool system you guys have built!

The sudo shutdown -h now --> [shell] works, and I was able to setup the autoloading as well. Unfortunately, now I’m running into another problem…

When I try to load my patch, it seems to work about 1/3 of the time, regardless of if I autoload it via the module, open pd manually and open it, or load it directly from the command line as pd Pd/main.pd.

When I try and load it manually, the terminal repeatedly says watchdog: signaling pd.... I assume that the same thing is happening when I autoload, but that it is just failing silently.

I’m trying your logging suggestion from this post, and I’ll add anything that seems strange when I have a bit more time to test. But in the meantime, I’ve tried adding delays before starting my dac and loading all the audio files into the soundfiler, but that hasn’t helped…

Any suggestions would be greatly appreciated, thanks!

What do you mean by starting your dac? What do you have to do to make it work again? Restart the whole system until it works, or only PD?

Sorry, I meant starting the dsp…

I believe I have to restart the whole system (and even that doesn’t work every time), but honestly, I did not test that thoroughly enough to be sure yet. I think the whole situation may have been complicated by the fact that when I was testing most recently I used the & flag when launching pd, so maybe that’s why CTRL + C didn’t stop the watchdog: signaling pd... output on the command line? I can’t get the pd window to close (I’m using ssh -X to remote into the pi), but the OS seems to functional otherwise.

Perhaps it is also useful to note that when the autolaunch fails to work, I can still open a new copy of pd without any problem (presumably while an old one is silently failing in the background), but when I try and open my patch, I get a spinning wheel of death and the watchdog posts start to appear on the command line.

The more I describe this problem, the more it sounds like it’s a problem with the patch… :confused:

In order for ctrl+c to work when you start a process with & at the end, you have to use fg command to bring that background process into ‘foreground’, then ctrl+c will work.

Did you modify any of the patchbox scripts that start PD? Is your system up to date? I think we had fixed something related to service initialization order a few months back. Do patchbox update just to be sure and try again if there were any updates installed.

Ah good to know about fg… thanks!

I have not modified any of the scrips, and the system should be completely up to date (I updated from the wizard recently), but I’ll give the update another try this afternoon when I’m back at the installation.

On a related note, I just came across the Pisoudn App on the documentation website. Is it possible to use it directly with patchbox os without a pisound connected to the system? If so, I think that might be a good work around for restarting the patch/system until I can resolve the watchdog issue…

Thanks.

crash_01.log (131.5 KB)

So I’ve followed the instructions linked to in this post, and I’m not sure how to decipher what exactly is going wrong, but watchdong: signalingpd... does occur many times in the log file (see attached). Does anyone have an idea of what is going wrong and how I can fix it? As I mentioned before, I tried adding delays to all the loadbangs in my patch, and I’m not sure what else could be causing the issue…

Thanks!
-eric

I sorted out the problem…

pd was not happy that it was already receiving a stream of serial data while it opened the serial connection, so a delay on the arduino side fixed the issue. Thanks for your help along the way @Giedrius!

1 Like

So is Arduino the problem? how can you add a delay on arduino, can you share your .ino? Thx

yes, exactly.

the entire code is a bit of a mess, but what I did to solve the problem was just wait until I pressed a button for the first time before allowing the Serial connection to send anything. Note that send_active is initialized to LOW and I’m using the internal INPUT_PULLUP resistor on the arduino, so the switch is LOW when pressed:

if (send_active) { // send the max value to pd over serial
  Serial.println(current_max_val);
}

// get button state
button_state = digitalRead(button_pin);

// turn on serial sending once the button is pressed for the first time
if (send_active == LOW && button_state == LOW) { // remember, button logic is inverted...!
  send_active = HIGH;
}

Thank you! I am a noob on Arduino can you please check the code I made and apply your solution in it?
lucibox_midi_control.zip (6.8 KB)

I also found this https://github.com/tttapa/Control-Surface