Also yes it's possible to specify a particular midi channel with ctlin. ie [ctlin 13 1] will limit the output to cc 13 on chan 1 - as in your C code above. So you could do that multiple times instead of route/spigot, but it depends on the purpose as to which would be more complex, I reckon.

Not sure about the programmatic restarting, I suppose it may be possible to use:
[r pd]--->[route dsp]
And then use the output (0 when DSP is off) to inform DSP restart with a {; pd dsp 1} message...
However I would be surprised if that didn't cause some instability and crashiness, at the very least dropouts when it's switching...

Perhaps see if your ALSA drivers are up to date/right, or try running with OSS drivers (if supported - 'pd -oss').

Yes it seems that way. Ironically noise is the solution to counteract the noise. Found some details via the PD mailing list:
http://lists.puredata.info/pipermail/pd-list/2009-07/070992.html

Hi,
I'm currently scavenging the net to find an answer to a problem I've encountered in a couple of patches recently. This thread is one of the closest similar things I can find to what I'm experiencing. My particular unwanted noise seems to manifest as a sort of bitcrush style 'effect'.

I'm still looking into it but I think this might be to do with feeding nan (not a number) or audio multiplied by zero into freeverb~, or multiple freeverbs. After a few seconds of this it freaks out and noise comes from the freeverb~, and seemingly other objects in a slightly irrational manner. It can be alleviated by feeding non-zero into freeverb~ again. So a workaround would be to have very low noise constantly > freeverb.

Sounds like it's the same thing. Going to test it this evening and hopefully post a bug report. I think it'll be specific to the version we're using (can't remember which one) and it seems that 'nan' handling is specified at compiler level, so possibly just a bad compiled release of freeverb.