Is midipolyaftertouch broken in csound?

Question

I'm not having much luck with the midipolyaftertouch opcode. Basically

kPea init 0.1
midipolyaftertouch kPea, 1, 0.1, 0.9
printk2 kPea

does not actually respond to polyphonic aftertouch messages. On the other hand, a manually coded rough equivalent

kPea init 0.1
kstatus,kchan,kdata1,kdata2 midiin
if (kstatus==160 && kchan==1) then
    kPea = kdata2 * 0.007
    printk2 kPea
endif     

works fine. So is this a known bug in midipolyaftertouch ? I can't find any usage examples for midipolyaftertouch, besides those from the manual, so I'm guess hardly anyone used it... By the way aftouch gets the channel not the per-note after-touch (pressure), i.e. aftouch queries kstatus == 208 (and actually does work, but of course it's not per note). For the difference see this.

I'm using Csound version 6.13 beta from inside Cabbage 2.3.0 on Windows (because that's what ships with that version of Cabbage).

Answer 1

There's another opcode namely polyaft that actually works, following the documentation

kPea init 0.1
inote   notnum          ; note number
kPea    polyaft inote, 0.1, 0.9
printk2 kPea

Looking at the C source for midipolyaftertouch it is actually indexed exactly the same way as for polyaft. So based on that I tried:

kPea init 0.1
inote   notnum          ; note number
midipolyaftertouch kPea, inote, 0.1, 0.9
printk2 kPea

and this actually works too.

In the MIDI API jargon, "MIDI controller [number]" (usually) means key/note [number]... unlike in world of DAWs where one uses e.g. "multiple MIDI controllers" to mean several keyboards, not several keys of the same keyboard... Also, Csound has a notion of multiple controllers in the latter/DAW sense, selected by the -M startup switch, although it calls them "MIDI devices".

The code example for midipolyaftertouch from the documentation can't possibly work unless you just try it with D0 as the key/note; insert joke about the broken clock here. Interestingly the documentation was written by the source code author for that opcode, so it wasn't a case of someone else misunderstanding the code...