software, pd

almost there / final steps

on the pd end of things, we just need to put together the elements from before, and make things start up on start-up.
in terms of the UI, a pd patch typically will use [terminal_tedium_adc] (for the CV inputs), [tedium_input] for the gates and switches; and [tedium_output] for gate outputs.
a most basic patch might look like so ... not really doing anything much at all:

the [loadbang] object in the centre puts out a bang when the patch is loaded and turns on the dsp (note that [dac~] and [adc~] aren't pictured). a little delay is required for that to work, thus [delay 300]. the bang also turns on the [metro] object for the ADC and inits the spidev ([open().
you have to run the patch with sudo because of the GPIO/SPI access.
the corresponding pcm5102a sketch would look basically similar, except for the GPIO numbers and the init message sent to terminal_tedium_adc (see here)

start up script

now, we need to come up with a start-up script, in which we launch pd and possibly a few other things as well. an example can be found here; something like this should be called during boot-up by rc.local.
note: when you've used the install script, the above script will be called rt_start and already live in /home/pi/terminal_tedium/software/.
you can easily expand it to run a pd patch on start-up, too. simply add (before the line that says exit) something like

## start pd
sudo puredata -nogui -rt /home/pi/nameofpatch.pd  &

note that -nogui flag. this is because there's no gui.
(more complex things (like changing patches) is possible of course, but this requires some more complex little programs running in the background. see the OSC client for some pointers.)
if it doesn't work, make sure the script is executable: sudo chmod 755.
If you get sudo: puredata: command not found use the full path to the binary.

finally ..

optimisations etc. there's lots of room for improvement/experimentation. you might consider using a different distribution, there's realtime kernels or using jack* (not ALSA). you're on your own here though.
some simple/basics things can be found in the rt_start script (also installed via install.sh, and invoked by rc.local) (in particular, note the line echo -n performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor).
in terms of audio latency, the best results (with pcm5102a) i got is with something like:

sudo puredata -noadc -nogui -rt -r 44100 -audiobuf 5 [yourpatch].pd ; though this is unlikely to run stable. you'll have to experiment with the size of the audio buffer.