@jameslo I should have thought of the space escaping myself Avoiding spaces in file names is nevertheless a good practice IMHO.

The slash is no problem, the comma and the white space are though. What @whale-av says is correct but you can do the conversion to ASCII and back to a symbol all in Pd. Here's how (separate the two messages, and combine them with the ASCII white space in between - 32):

First off, remove any GUI objects (number atoms, sliders, bangs etc.). Replace all GUI bangs with the message "bang" or the object [bang]. If there are parts of the patch that don't operate all the time, it's a good idea to put a [switch~] in subpatches and turn their DSP on and off whenever possible.
Replace all graphical arrays with the [array] object.
About the crash when you turn on the DSP I have no idea. You could launch Pd via gdb to debug it, or launch it like this from the terminal:
pd -open /path/to/your/patch -stderr 2>name_of_your_log_file.log
And then read the .log file which will be in the same directory as your patch or the directory you launched Pd from, not sure which of the two.

Nice one! Thanks for sharing!

@EEight not a C -> Pd guru, but I have written a few externals. A Ninjam Pd external sounds fun. I have never used Ninjam before, I only recently heard about it. I could take a look at the code and see if it's possible for me to port it to a Pd external... I do have some time, but not much.

Most of the iem stuff are available through apt-get. Just type apt-cache search ^pd- and you'll get all the available Pd packages. Then install via sudo apt-get install <package-name>.

with [oscparse] you should also se [list trim] to trim out any identifier. Then you can send the output to [route] and use the OSC addresses as arguments to [route]. If though you have an address that goes deeper than one work, e.g. /my/osc/address then you'll probably need three cascaded [route] objects where each takes one of these words as an argument.

Haven't tested David's patch, but it's clearly using the now native objects [oscparse] which is just what you need along with [netreceive -u -b] for receiveing OSC messages. No need for externals any more.

Sure Teensy is a great solution, that's what I usually use myself. You don't need to use it as a MIDI device, raw serial will also work fine. The Raspberry though could also do the job, since it's I2C and the Pi supports this protocol.
We have no idea which OLED you're talking about and what code already exists to control it. If you provide more info we'll be able to provide more help.

Using an Arduino is another option. Are you using a Raspberry Pi or something similar for that?

You can also just click on a number atom in a locked patch and type the number you want (0.5 for example) and then hit enter.

You can set your [metro] to 125 to trigger the fast bang, which in turn will trigger a counter. The counter will trigger the slow bang every four counts, and it will reset itself.

What's the size of the table? It could be that [metro] fires faster than [tabwrite~] is able to draw to the table. You should calculate the [metro] speed according to the size of the table and your sampling rate.

Here's a version without [fexpr~] which is a rather expensive object:
(The [sig~] and scope are there only for concept proofing)

There are no externals I'm aware of that shouldn't be trusted. I'm pretty sure that if something nasty appears it will become known across the Pd community lightning fast. I think you should just go ahead and download whichever external you want.

Works fine for me on 0.50. Why not upgrade to the latest Pd?

@Boran-Robert please don't recommend Pd-extended as it is not maintained since 2013 or something like that. It is even not included in Pd's website download page. When people start using it, it often leads them to confusion. Purr Data is the replacement for it.

[snapshot~] will only give you the last value of the previous sample block, not good for any operation on all samples. Why don't you try [expr~]. For XOR you can do this [expr~ $v1^$v2]
If you want a specific number of bits (say 8-bit), add 1 to a bipolar signal and multiply it by half the resolution. For example for 8-bit do this:

[osc~]
|
[+~ 1]
|
[*~ 127.5]
|
[expr~ int($v1)^int($v2)]

or do everything in [expr~] like this:

[osc~]
|
[expr~ int(($v1+1)*127.5)^int(($v2+1)*127.5)]

That should work

How about "all $1" to [clone]'s inlet?

You don't necessarily need Jack, ALSA can do just fine, if you get drop outs make sure to increase the block size.
As for running Pd on boot, you can use crontab to do this and not mess with rc.local. Don't know if it's a better practice, but it works for me, also I don't need to start Pd as root. Type crontab -e and hit enter to edit it with nano. At the bottom of the file write:
@reboot sleep 5 ; pd -no gui /home/pi/patch.pd &
Hit Ctl+o, enter, then Ctl+x to exit. After you reboot Pd should launch. Make sure to delete the line in rc.local though.

Don't know if this will solve the problem. As for the priority issue, go to /etc/security/ and type sudo nano limits.conf. At the end of the file put the following:

@audio   -  rtprio     98
@audio   -  memlock    unlimited
@audio   -  nice      -19