Andy Maskell

Does anybody know of any methods, routines or externals that can convert hexadecimal bytes to decimal integers and back again?

I‘m wondering if [sprintf] can do this?

Does anybody know of any methods, routines or externals that can convert hexadecimal bytes to decimal integers and back again?
I‘m ... 

hex-to-dec-conversion-and-back

grafik.png

Thanks Roman. I thought that there should be a simple way to do it!

I did find an ancient package called Lobjects written by Peter Elsea in 2002 on maxobjects.com that does some conversions but much of the functionality in that (extensive) package is now incorporated into Max and the download site for the package and objects no longer exists. Pity because it does contain a number of other gems too!

Oh! Hang on, it's still available on his personal website - 

and his original university repositry is still there too -

http://artsites.ucsc.edu/ems/ftp_files_ems/Lobjects/

He was obviously a very bright star in the earlier days of electronic music. His personal website contains a whole raft of useful tutorials on matters 

It's perhaps of historical interest to note that in his technical reference to Lobjects, he's concerned about the then current limitations of only having computers with a maximum of 128Mb of RAM!!!

Oh! Hang on, it's still available on his personal website - http://peterelsea.com/lobjects.html

and his original university repositry is still there too -
http://artsites.ucsc.edu/ems/ftp_files_ems/Lobjects/ 

He was obviously a very bright star in the earlier days of electronic music. His personal website contains a whole raft of useful tutorials on matters musica electronica!

lobjects have been highlight of 3rd party externals for me over many years.

still, Romans suggestion to use sprintf is better in my eyes, one does not have to fiddle arround to remove "h" and there is no > 255 truncation limit,

for arbitrary list length, sprintf, iter and thresh would do the trick.

image.png

lobjects have been highlight of 3rd party externals for me over many years.
still, Romans suggestion to use sprintf is better in my eyes, one does not have to fiddle arround to remove "h" and there is no > 255 truncation limit,
compared to lhex.
for arbitrary list length, sprintf, iter and thresh would do the trick.


Thanks @SourceAudio. I'll add those ideas to my Sandbox file.

It's a bit of a shame that my attempts to hack in to my mixer's audio level service has come to dead end now, as even though I can extract the audio levels that I'm looking for in the UDP blobs it sends, there is currently no way that I can currently command the custom meter object in the software (Mixing Station) that I am using.

Thanks @SourceAudio. I'll add those ideas to my Sandbox file.
It's a bit of a shame that my attempts to hack in to my mixer's audio level service has come to dead end now, as even though I can extract the audio levels that I'm looking for in the UDP blobs it sends, there is currently no way that I can currently command the custom meter object in the software (Mixing Station) that I am using. 

Questions and advice about using the sprintf object go back a ways....

 object indexes every new message it receives, which results in ever-increasing memory usage as your patch runs. The somewhat recent advent of 64-bit memory addressing means that the memory usage is 

 of a problem. However, the above is still true.

For various reasons — efficiency is one of them — all symbols are cached in Max, and they are never freed unless you quit the Max application. Symbol-caching is a feature of Max that’s been around for a long time, and it’s been the recommendation of similar duration that we don’t suggest relying on patching/objects that generate tons of unique symbols. Even though 64-bit addressing does change things, I would still advise caution, depending on your 

(And it would be impolite to not pause at this point to thank our mutual friend E.J. for his clear explanation of this to me a long time ago)

Questions and advice about using the sprintf object go back a ways....

The sprintf object indexes every new message it receives, which results in ever-increasing memory usage as your patch runs. The somewhat recent advent of 64-bit memory addressing means that the memory usage is less of a problem. However, the above is still true.

For various reasons — efficiency is one of them — all symbols are cached in Max, and they are never freed unless you quit the Max application. Symbol-caching is a feature of Max that’s been around for a long time, and it’s been the recommendation of similar duration that we don’t suggest relying on patching/objects that generate tons of unique symbols. Even though 64-bit addressing does change things, I would still advise caution, depending on your sprintf usage.

(And it would be impolite to not pause at this point to thank our mutual friend E.J. for his clear explanation  of this to me a long time ago)

Thanks Gregory. I assume that if I were converting 2-nibble hex bytes, using the 

method that @SourceAudio recommended, that would only generate a maximum of 256 symbols though? If the same values were to be presented to 

 more than once, I pressume that the existing symbols would get re-used or over-written? Or would the longer hex lists themselves also create unique symbols?

Thanks Gregory. I assume that if I were converting 2-nibble hex bytes, using the [iter]-[sprintf]-[thresh] method that @SourceAudio recommended, that would only generate a maximum of 256 symbols though? If the same values were to be presented to sprintf more than once, I pressume that the existing symbols would get re-used or over-written? Or would the longer hex lists themselves also create unique symbols? 

FWIW Jeremy updated the lobjects for Peter a few months back.

's-lobjects-macos-universal-x86_64-and-arm64

FWIW Jeremy updated the lobjects for Peter a few months back.
https://cycling74.com/forums/peter-elsea's-lobjects-macos-universal-x86_64-and-arm64

 every time, Max will use that symbol from the symbol table (as um... a pointer to a string, I think).

Yep. · If you convert an integer X to a symbol N times per second and the integer is X every time, Max will use that symbol from the symbol table (as um... a pointer to a string, I think).

that is one of the reasons why i only convert stuff bytewise. (the other reason is that i would not know how to do it for longer strings /greater values anyway. ) (and for midi, you dont really want to enter the whole string in decimal values anway, rather only controller or note values.)

on my wonderful OS9 operating system RAM fragmentation is a real issue, far more than anywhere else. if you work with max, you should reboot twice a day, i.e. not only restart max from time to time.

but i also think that for 256 values you are on the safe side - and i would not be so sure if third party objects of the same functionality such as sprintf or buffer~ not maybe do exactly the same.

that is one of the reasons why i only convert stuff bytewise. (the other reason is that i would not know how to do it for longer strings /greater values anyway. ) (and for midi, you dont really want to enter the whole string in decimal values anway, rather only controller or note  values.)

on my wonderful OS9 operating system RAM fragmentation is a real issue, far more than anywhere else. if you work with max, you should reboot twice a day, i.e. not only restart max from time to time.


this test has now been running for a good while....

As you can see limit seems to be thresh with max 4095 items.

37074 x 9999 conversions int-hex-int have taken place

and in Activity Monitor Max gained as much memory :

I guess any symbol manipulating tool in Max

like for example regexp will act similar.

If I understand it correctly, you need this conversion because

that mixer software sends meter readouts as sysex but

insted of midi sends hexadecimal represenation as plain text via UDP/OSC?

this test has now been running for a good while....


As you can see limit seems to be thresh with max 4095 items.
37074 x 9999 conversions int-hex-int have taken place
and in Activity Monitor Max gained as much memory :
fresh started without any patch:

--------
I guess any symbol manipulating tool in Max
like for example regexp will act similar.
If I understand it correctly, you need this conversion because
that mixer software sends meter readouts as sysex but
insted of midi sends hexadecimal represenation as plain text via UDP/OSC?


The Mixer sends the level signals out in an arbitrarily long blob on the end of a UDP/OSC style message. The header has non-standard OSC style addresses followed by a variable number of integer parameters including a blob length value. The blob tagged on the end is generally made up of 32 bit float values for each level but without being able to decode the header first, you can not predict where the blob starts! There can also be anything from 4 to 96 such values in the blob depending on the message type, of which I'm only interested in two, that occur at varying positions depending on the message type! It's a nightmare to try to understand without breaking it all down into hex nibbles (x00 - xFF) that I can compare with the examples in the document I have. On top of that, the level decoding is not as simple as it sounds as it's neither a linear nor logarithmic scale - instead, the scale is formed from four linear bands that collectively appoximate to the desired logarithmic dB scale. It's more like a university level project than a hobby!

The Mixer sends the level signals out in an arbitrarily long blob on the end of a UDP/OSC style message. The header has non-standard OSC style addresses followed by a variable number of integer parameters including a blob length value. The blob tagged on the end is generally made up of 32 bit float  values for each level but without being able to decode the header first, you can not predict where the blob starts! There can also be anything from 4 to 96 such values in the blob depending on the message type, of which I'm only interested in two, that occur at varying positions depending on the message type! It's a nightmare to try to understand without breaking it all down into hex nibbles (x00 - xFF) that I can compare with the examples in the document I have. On top of that, the level decoding is not as simple as it sounds as it's neither a linear nor logarithmic scale - instead, the scale is formed from four linear bands that collectively appoximate to the desired logarithmic dB scale. It's more like a university level project than a hobby!

most things in midi fit into a single byte because they are 7 or 8 bits. 

and in most documentations everything is written with space between the bytes even if represents something "longer".

so i believe it is fine to start processing and displaying everything as single bytes - and when wrong decimal represenations of a 14 bit value appear you will notice and can still change the patch.

the original [Lhex] from 1997 is also not able to process more than 0-255 and will truncate 257 decimal to 01 hex.

to my understanding, when you limit yourself to single bytes, you will only create up to 256 strings in RAM - but for each instance. (which somehow recommends to use a coll with pregenerated values instead if you plan to have hundreds of copies?)

>>where do you get that limit of 256 ?

most things in midi fit into a single byte because they are 7 or 8 bits. 
and in most documentations everything is written with space between the bytes even if represents something "longer".

so i believe it is fine to start processing and displaying everything as single bytes - and when wrong decimal represenations of a 14 bit value appear you will notice and can still change the patch.

the original [Lhex] from 1997 is also not able to process more than 0-255 and will truncate 257 decimal to 01 hex.

to my understanding, when you limit yourself to single bytes, you will only create up to 256 strings in RAM - but for each instance. (which somehow recommends to use a coll with pregenerated values instead if you plan to have hundreds of copies?)

Boy, it's been a long time since I checked in here. Lobjects now have an attribute-- maxlistsize-- set its as large as you like.

Lhex only produces values up to FF because that was all that was needed at the time. It produces symbols that are understood by some other objects. (Sysex messages. mostly.) Number will display hex of any size.

Boy, it's been a long time since I checked in here. Lobjects now have an attribute--  maxlistsize-- set its as large as you like.

Hex to Dec conversion and back - and the re-discovery of an electronic music maestro!