@peter-ostry My personal preference is to use all CCs, because a CC is only 3 bytes long, and can be shorted to two if there's a stream of the same one, by using "running status", where the first (status) byte is only sent when it changes.
It's also the easiest thing to program a hardware MIDI controller to send directly, i.e. for one where you can set which CC each control takes. Plus it's easier to use CCs than either NRPN or sysex in Ctrlr.
One problem with CCs is that there are only so many of them (128) and some of them are best not used for this purpose, because they have very specific meanings. Realistically, there are only maybe 100 that are useable, in most cases.
The other problem is that they only send 7 bits of data (representing 0-127).
The next choice would be NRPNs. They're longer than a CC but normally shorter than a sysex message. They can send 14 bits of data (representing 0-16383) and it's not essential to send both bytes at once, which has a big advantage;
Most MIDI controllers encode their knobs to 7 bits. On some, it's possible to set a control to physically send either the top 7 bits (course value) or the lower 7 bits (fine).
Failing that, it can be done in something like Ctrlr - the physical MIDI controller can sent CCs representing course and fine values, which Ctrlr can then translate to course and fine NRPN values.
I guess anyma phi needs to use NRPNs rather than CCs for those two reasons - two many parameters to fit in the useable range of CCs, and needing more resolution than 7 bits.
It could be done in sysex, but there are very few physical MIDI controllers that can do that at all, let alone well. Having made a few "panels", and changes to panels, in Ctlr, I much prefer using CCs, but I can see that might not be an option.
