Hello, I need to control a software remotely and it needs a 30 bit unsigned int as control values, is possible in anyway to send this value from pure data? I am able to control it as long as the values aren't expressed in scientific notation. There's a workaround for that? Thank you

@seb-harmonik.ar said:

can you send the number as a symbol? if so you could split it the number into 16 bits for both low and high parts, turn both into symbols, and then concatenate the symbol back together and send it

Yes, symbols are fine! Can you suggest how can I do this practically?

[l2s] converts a list into a symbol.

Let's suppose I have to send 2^29
the integer value is: 536.870.912,
pure data shows the number as: 5.36871e+008.

How can I split it in two parts and then join them in a symbol to send the correct value?

actually it's as simple as [makefilename %u] (my other method wouldn't have worked because I was thinking in binary instead of decimal, where you can just concatenate the digits. You could do the same with decimal but only in powers of 10, and binary #s are powers of 2)

Thank you very much, it works! But I have a problem with numbers higher than 24 bits, because there's an error of 1, so for example instead of 0000 0000 0111 1111 1111 1111 1111 1111 I get 0000 0000 1000 0000 0000 0000 0000 0000 and since every bit is an option on the software side I get 23 options checked instead of 1 or viceversa. Maybe the problem is that I sum every bit checked... But I don't have other ideas to make this work... Any idea to avoid this rounding? Here I post the patches to help you figure it out LayerConditions.pd Condition.pd The patch to open is LayerConditions, the other is an abstraction inside it. Thak you very much for the help.

In the iem/iem_dp library are objects for this. The bad news is that you have to compile it yourself, as it isn't in Pd-extended.

Fred Jan

@Patcher88 well, it is correct within pure data so whatever is going wrong is somewhere in the pipe between the symbol from pure data and the program you are receiving to. Would it work just to subtract 1? what happens if you send 0? (does it send 1 instead?)

Oh, never mind. The issue is due to floating-point representation limitations in 32-bit (only 24 bits of significand). I'll see what else could be come up with. perhaps representation of the numbers in base 10, then combining with symbols like my first suggestion

I've discovered that the program receives Hex numbers, so I think I'll rewrite the patch to read the toggles as a list of binary numbers and converting them to hexadecimal should work because I wouldn't use integers anymore and therefore I don't have problems with floating point precision ecc... There are some objects to handle binary numbers, hex, and to convert between binary and decimal or I need to write them by myself?

perhaps these http://sourceforge.net/projects/pd-issiconvert/

Problem solved! I've edited my abstraction so that the 30 toggles are splitted in 4 bytes, every byte outputs the number in hex form and a complete hex message is created by merging every byte. Now it works wonderfully! Thanks to everyone for the help|!