ah, this is an area Ive grappled with a few times, each time thinking I must write it down, and then not getting around to it.
so I'll give what I can remember from last time I looked, as a discussion point, it may be slightly inaccurate, but hopefully will get the ball rolling
k-rate - integer : straight encoding
k-rate - string : need to check i guess 8 bit char
k-rate - fraction (bi and unipolar) 1<< 21, so +/-64 = 6 bits, so 4/5 bits headroom (sign bit 31)
audio : 1 << 27 so really +/- ~ 15.0 , so 4 bits 'headroom' (sign bit 31)
(with the k-rate fractions there are then various 'interpretations' e.g. linear frequency , pitch, phase)
the tricky bit, and Im only just now getting the feel for it.... is then shifting things into the right ranges, and often combining left and right shifts e.g. (a << 7 ) >> 2) = a << 5, but with much less change of overflow.
audio encoding, there is no -1/+1 thats just a display representation, the DAC is using signed 32 integer encoding.
int16_t delayline - less precision, but longer delay line. convert by shifting appropriate number of bits.
when I come back to this , I just break out the disp/hex and start attaching dials, or looking at various 'simple' objects, though this time around Ive started creating some print objects in the community library, which I planned to have the various encodings for...
(e.g. there are certain conventions used for encoding pitch, frequencies etc)
of course, I agree a detailed user guide is a great idea. if you are exploring this, why not write it up and share as you go along, as we start to get more users coding objects , it will become increasingly important and useful resource.