Max also has bendin/benout, but the 'x' variance seems to be newer and with a different range, cause the old - but still existing - bendin/bendout objects in Max are only 7 bits (from 0 to 127). BTW, Miller, can you confirm pitch bend messages were only 7 bits back in the day? And do you know when this changed to 14 bits?

Funny enough, max has inconsistencies with other objects. 

Quite recently, in the 7.2.0 version (Max is now at 7.2.4), the objects [midiformat] and [midiparse] were finally updated to include 14 bits pitch bend messages, via a '@hires' attribute. The ones in cyclone are still only 7 bits (0-127).

We (Me and Derek) just updated these objects in our currently unreleased cyclone update project to include 14 bit pitch bend messages. In conjunction with Pd's [midiin] / [midiout], they can replace [bendin] / [bendout] related objects, but it is just too clumsy for that. And the silly thing is that they chose for them the more intuitive range from -8192 to 8191, making it inconsistent to xbendin/xbendout. We adopted this more intuitive range anyway.

I was then checking bendin/bendout in Pd to see if they were also from -8192 to 8191 and then found this inconsistency.

So, in short: yeah; xbendin/xbendout in cyclone can be used for a consistent range between MIDI in/output. But then I still think these objects are quite obsolete, cause bendin/out are basic elements present in vanilla. And I it is also weird to me to have them as a way to replace existing objects in vanilla.

Cool. Whatever the solution is, I'm hoping for a vanilla fix so both pitch bend in/out messages are consistent in vanilla. I'm ok with any solution, but I'm just hoping that both make use of the more intuitive -8192 to 8191 range.

cheers