Hi, I am looking for a way to decode 4bytes/32bit encoded in 5 bytes extracted from midisysex.
They look like this:
0---1111 | 01111111 | 01111111 | 01111111 | 01111111 (where --- are unused and all 0 need to be cut off)
or in other words:
0 - - - a7 a6 a5 a4 | 00 a3 a2 a1 a0 b7 b6 b5 | 00 b4 b3 b2 b1 b0 c7 c6 | 00 c5 c4 c3 c2 c1 c0 d7 | 00 d6 d5 d4 d3 d2 d1 d0
should become:
a7 a6 a5 a4 a3 a2 a1 a0 | b7 b6 b5 b4 b3 b2 b1 b0 | c7 c6 c5 c4 c3 c2 c1 c0 | d7 d6 d5 d4 d3 d2 d1 d0
How could this be done? I am not a bitshifter guy yet.
my attempts have failed miserably so far.
cheers

@bang Not sure exactly what your messages are and need to be, but here are some tools that might help...... hex_bin_float.zip
[sel 0] after [list-drip] will remove the zeros. --- might just be ignored in Pd if you are lucky.
David.

@bang Are you using a version of Pd compiled for 64-bit floats?

Pd doesn't have an integer data type.

If you're using a standard build of Pd, then the number will be converted to a 32-bit float, with 24 bits of precision in the mantissa (23 bits physically stored, with one implicit "1" to the left of the binary point that is not stored). So the conversion will drop the "d" bits, gone forever.

2**24 + 1: 1.67772e+07
2**24: 1.67772e+07
equal: 1    :-O

A 64-bit float version of Pd would have 54 bits of precision (53 physically stored), more than enough. But (I guess) DSP might be a bit slower.

How will these 32-bit integers be used, btw? Depending on the usage, you might be able to live with a pair of 16-bit words.

Or, use Max/MSP or SuperCollider, both of which have a signed 32-bit integer datatype.

hjh

@bang said:

I am not a bitshifter guy yet.

I applaud your positive attitude and am looking forward to when you become a card-carrying bitshifter.

Does this give you any insight?
bitshifter.pd

The numbers in the bitwise AND operations are called "bit masks", and the operations below just shift the masked bits into their proper place. You have to enter your numbers right to left to make the addition work. Finally, you have to sit down with a pad, pen, and decimal to binary converter to convince yourself that it's working.

Nice suggestions!
I will dig into it soon.
cheers

@ddw_music said:

@bang Are you using a version of Pd compiled for 64-bit floats?

I don't know. How can i find out? I am using PD on different devices/OSes. The current Projekt should run on RaspberryPIOS 32bit, so PD's float is probably 32 bit as well? Shifting the upper 8bits [>> 24] (for 32bit into 5 bytes/7bit tranlation) could be an Issue ...?

How will these 32-bit integers be used, btw? Depending on the usage, you might be able to live with a pair of 16-bit words.

Well, the device (Kemper) I am trying to communicate with, sends/receives these values in MIDI Sysex packages. Some parameter can be accessed by these 32bit addresses, but some are undocumented. So, let's see where this leads.

Or, use Max/MSP or SuperCollider, both of which have a signed 32-bit integer datatype.>

I started prototyping this in PD cause I am kinda familiar doing midithings in PD.
Maybe I move it to python later on (learning it right now).

btw: bitshifting is developing quite well
Thankx again

@bang said:

Well, the device (Kemper) I am trying to communicate with, sends/receives these values in MIDI Sysex packages. Some parameter can be accessed by these 32bit addresses, but some are undocumented. So, let's see where this leads.

If it's only an ID (and you won't be doing math on it), then you can safely represent them as 4 bytes, or 2 16-bit words, or whatever. It would get more difficult if it were, "after reassembling the integer, I need to multiply by 5 and subtract 7" but if you're not doing that, then it should be OK to just continue with the present approach.

hjh

@ddw_music said:

If it's only an ID (and you won't be doing math on it), then you can safely represent them as 4 bytes, or 2 16-bit words, or whatever. It would get more difficult if it were, "after reassembling the integer, I need to multiply by 5 and subtract 7" but if you're not doing that, then it should be OK to just continue with the present approach.

Thats what I thought as well.

After some messy patching with execution order issues, this is seems to do the trick:
[expr int(($f1 & 15)*16 + ($f2 >> 3));
int(($f2 & 7)*32 + ($f3 >>2));
int(($f3 & 3)*64 + ($f4 >>1));
int(($f4 & 1)*128 + $f5]

Not yet tested with real midi messeges, but I am confident.
cheers