@iainmccurdy unfortunately I searched on Cabbageaudio forum, couldn’t find the talcum powder thread. 
On a serious note, I am also starting to think that there is something very odd about aftertouch. If I fire up Midi-Monitor, (or even Geert Bevin’s Juce based Midi monitor: https://github.com/gbevin/ReceiveMIDI/releases) I see that the Blocks Seaboard isn’t sending Polyphonic Aftertouch at all. And that makes sense. As it isn’t polyphonic- each channel is now a monophonic note, so it is actually sending out ChannelPressure (or Monophonic Aftertouch) - per note channel.
I researched the Csound docs and there used to be a chpress opcode: https://www.eumus.edu.uy/eme/ensenanza/electivas/csound/materiales/tutorials/nelson/
However I think that has been depreciated. There is however midichannelaftertouch.
What value I am seeing from aftouch opcode is quite strange, when I printk the value it is interlacing a 0 between each ‘real’ value. And when there are no new values (as checked in Midi-Monitor) it is still spitting out 0’s.
Using midichannelaftertouch I was able to get rid of the interlacing 0’s issue between real values, but not the constant stream of values.
I’m sure that this isn’t a good thing for Csound to be spammed with thousands of 0’s of aftertouch information, which are not being generated by the Seaboard Block, as checked by using Midi-Monitor & ReceiveMidi.
If you are able to get RecieveMIDI run:
receivemidi dev (device name) pp
and compare it to:
receivemidi dev (device name) cp
So the above commands for me show nothing for pp (polyphonicpressure) and good data for cp (channelpressure).
This issue possibly could be an issue with Csound itself? I have tested in QtCsound and there is the same spamming of Aftertouch values.
Having looked at the GitHub Csound source it looks like midichannelaftertouch is simply averaging out all of the polyphonic aftertouch values (OOps/midiinterop.c) so that would explain why its getting the stream of 0’s similar to aftouch:
int midichannelaftertouch(CSOUND *csound, MIDICHANNELAFTERTOUCH *p)
{
MYFLT scale;
IGN(csound);
if (!p->h.insdshead->m_chnbp) {
return OK;
}
scale = (*p->hhigh - *p->olow) * dv127;
*p->xchannelaftertouch = *p->olow + p->h.insdshead->m_chnbp->aftouch * scale;
return OK;
}
After reading: https://www.midi.org/specifications/item/table-1-summary-of-midi-message it looks like poly and channel aftertouch are two very different status values.
I will look into this more when I have time. (maybe its a MacOS specific issue? I don’t know.) Aftouch does have that 127 init value behaviour- see below.
Thanks for the smoothing UDO, will take a look soon.