# Decimal to 17-bit 2's Complement Signed Number

I am trying to convert decimals, (0.05, -0.28, 25.00, etc), to a 17-bit 2's complement Signed Number. The parameter data I am sending is SysEX Midi Data (to some external Synthesizer). The data parameters are composed of 3 bytes.

For example, the example given is as follows:

• The parameter data to set the value to -0.02 is (07 7F 70) (Data2,Data1,Data0)

I was wondering if anyone could give me guidance for doing this in Java, here are the specifications I am going off of:

• The parameter data is a 17-bit number 2’s complement signed number.
• data2= Mix channel number and most significant bits (bits 14-16) of parameter’s data (with the format 0xxx xyyy, where xxxx is the mix channel number (0-15) and yyy are the uppermost bits (bits 14-16) of the parameter data.)

• data1= Bits 7-13 of parameter’s data

• data0= Least significant bits (bits 0-6) of parameter’s data

So, here is what I am able to assume so far:

• The 3 bytes is composed of 17 bits, + the 4 bits for sending #'s 0-15 (The Mix Channel)
• The 17th bit is the signing bit?
• The signing bit only needs to be set if It's a negative number, and in which that case needs to be formatted w/ 2's complement
• The highest bit for each parameters data byte is set to 0

With all this in mind, can someone help me understand, post, or help me write a function to format this 17-bit number from a signed decimal value? Binary Bit Adding / Subtracting In Java, Two's Complements, etc...It would be greatly appreciated it anyone has any example functions, or explanations!

Cheers

-
I'm going to start with the most obvious problem: 2's complement is intended for use with integer types. With that in mind, what does 2's compliment have to do with numbers such as 0.05 and -0.28? – Stargazer712 May 7 '13 at 18:38
You have 7-bit bytes? Still, 3 of them would make 21 bits, not 17. – Ingo May 7 '13 at 18:49
Yes absolutely, I meant to do that. Here it is. Page 5, Section 0E Specifically. alesis.com/stuff/contentmgr/files/0/… Ingo -- I know, I am a tad confused as well here mate, lol. – Mark May 7 '13 at 18:55
@Mark For future reference please don't cross post questions between Stack Exchange network sites. I'll tell DSP to delete their copy. Flag for migration in the future, please. Have a pleasant day. – World Engineer May 7 '13 at 21:33
@Mark Deleted copy on DSP.SE. As World Engineer says, you're better off flagging for migration than multiple-posting. – Peter K. May 7 '13 at 21:38

The value is scaled, so first you have to convert it into an integer. A 17-bit two's complement number has a range from `-2^16` to `2^16 - 1`, or `-65536` to `65535`. Therefore, for `-0.02`, you multiply it by `65536`, which gives you `-1310`. As Ingo pointed out, Java values are already in two's complement notation, so as long as you mask off the bits greater than bit 16, you are already good to go.

This assumes the display goes from -1.0 to 1.0. If the maximum value on the display is different, you have to divide the `-1310` by whatever the maximum value is. 100 gets pretty close to your example result, but it will differ for different parameters.

However, your three bytes are 7-bit bytes, but we just calculated it for 8-bit bytes, so you have to do some more screwy bit shifting to get it into the form it wants:

``````(0x1fae2 >> 14) & 0x7f = 0x07 # First byte
(0x1fae2 >> 7)  & 0x7f = 0x75 # Second byte
0x1fae2        & 0x7f = 0x62 # Third byte
``````

I'll leave it as an exercise for the reader to implement the first part in Java. If you pass in `0x1fae2` as `param`, Ingo's code works for the second part.

-
Great you made it clear how the deciaml numbers are being converted. But, wouldn't it be easier to just take `2*65536/100 * -1`, and since all java integers are in 2s complement, we already have the bit pattern. – Ingo May 7 '13 at 20:03
Good Info Karl and Ingo. @Karl Is your example for -0.02? You're three bytes are [07] [75] [62], whereas the example in the spec, to get -0.02, the bytes are [07] [7F] [70] – Mark May 7 '13 at 20:18
Yep, that would be easier, @Ingo. – Karl Bielefeldt May 7 '13 at 20:22
Ooohhh, I see....so depending on the specific thing Im editing, like for example, if the range is from -127 to +127, then thats the number I need to use for division? – Mark May 7 '13 at 20:51
That's right @Mark, although I should add that if the range only contains integers, you just use Ingo's function directly. – Karl Bielefeldt May 7 '13 at 22:17

Assuming that your parameter data are integers (like @Stargazer712 pointed out, 2s-complement) doesn't make any sense for non integer types) the following should do it:

``````byte[] encode(int channel, int param) {
byte[] data = new byte[3];
// note that param is already 2's complement number, we only
// need to split the bits apart (2x7 bits + 3 = 17)
// 0x7f = 1111111 binary, so as to get 7 bits
// 0x7  = 111 binary to get 3 bits
data[2] = (byte) (param & 0x7f);         // lowest 7 bits
data[1] = (byte) ((param >> 7) & 0x7f);  // next seven bits
data[0] = (byte) ((param >> 14) & 0x7);  // 3 remaining bits
// The channel must be placed 0xxxxyyy where xxxx are the 4 bit
// channel number, and the yyy are the 3 upper bits of the param.
// Hence, make sure we have only 4 bits shifted left by 3
data[0] |= (byte) ((channel & 0xF) << 3);
return data;
}
``````
-
I understand that you're shifting by 7 and then 14 bits, because it's only 7 bits per byte, but can you add some further explanations and the logic behind masking by 0x7F and 0x7, and shifting left by 3, etc, would help me alot! I prefer to understand something completely before coding it into my program – Mark May 7 '13 at 19:06
And in the case of -0.02, that is not an Integer, but a double/float, so the function you posted, it needs to accept input an decimal of "-0.02", and output the array of bytes [07] [7F] [70] – Mark May 7 '13 at 19:16
@Mark There is no such thing as 2's complement for non integers. Please take note. If you want 0.02, we need a specification how to represent it. I'll edit my post and add some comments. – Ingo May 7 '13 at 19:24
@Mark the spec doesn't appear to be matching the data... or rather, that multiple formats are associated with `F0 00 00 0E ...` commands. To this extent, look at webpages.charter.net/wingthing/html/s4/s4sysex_p08.txt which shows a number of different formats depending on what you are sending the data to. If it is an integer (range -24 to 24) it is stored in two's compliment. A decimal number is stored in some other format. – MichaelT May 7 '13 at 19:43
@Mark I believe you are seeing a number that is scaled somehow within the range. That `0.02` is being represented by `491376` - that it is not a floating point number that is being sent. – MichaelT May 7 '13 at 19:53