Tom Cosm

I'm working on a patch that gets a feed of crypto currencies (Bitcoin, Litecoin etc) which will ultimately control audio in Ableton Live.

My issue is a lot of the prices (that I strip from a json using [regex]) are up to 8 decimal places, and it's quite important that I have that level of accuracy.

Using [regexp] I am able to strip the price and feed it into a [flonum] (with 8 decimal places set in the inspector) no problem. I am also able to do basic math calculations with these flonums (I need to calculate a change in price if one occurs) and output the result to another flonum with the correct change no problem.

My issue is I need this final number to be split into individual characters including the decimal place, as I feed each into a [zl queue] which sequences them out as MIDI notes which trigger voice samples that read out the price/change in price.

I have been using regexp [[\\dl.] which does the job perfectly at splitting up all the character for me, however when I try to send the output of the [flonum] with 8 decimal places, it strips it back down to 6.

I know there's a whole world of pain when it comes to floats and large decimal place accuracy beyond my current comprehension, so I am reaching out to the gurus to find a solution.

Is there some other method I could use to get this result?

Could I potentially create a system than * the [flonum] by 1000 or so, then convert it back somehow?

Here is a chunk of the patch I currently have. Any insight whatsoever would be amazing!

I know there's a whole world of pain when it comes to floats and large decimal place accuracy beyond my current comprehension, so I am reaching out to the gurus to find a solution. 

looking-for-a-workaround-for-long-decimal-places-being-stripped

Unfortunately, Max floating point messages are still 32-bit floating-point(even though Max6 is a 64-bit app and runs 64-bit audio).

This means objects can compute with 64-bit precision, but when sending regular max floating-point messages between objects, those messages will always be 32-bit floating points.

(i read this in an addendum to Eric Lyon's book "Designing Audio Objects for MaxMSP/PD" which he posted somewhere on these forums in .pdf form as a freely available update to the book... if you search for his book you can find at least this short .pdf, and it's the very last paragraph of that .pdf..... not that you need all this info. just giving proper reference...)

In summary, you can't get the exact decimal precision you want(Max6 is sort of a transitional stage, in the future, everything will probably be 64-bit and you'll get more precision then... whether it's the amount of precision you'll need may always be an issue... but i think 8 decimal places would be possible then, reliably so...).

You can multiply by 1000 if you are willing to work constantly at that multiplication. As soon as you attempt to convert back by a divide or similar, it'll drop the same decimal places where it dropped before.

Unfortunately, Max floating point messages are still 32-bit floating-point(even though Max6 is a 64-bit app and runs 64-bit audio).
This means objects can compute with 64-bit precision, but when sending regular max floating-point messages between objects, those messages will always be 32-bit floating points.
(i read this in an addendum to Eric Lyon's book "Designing Audio Objects for MaxMSP/PD" which he posted somewhere on these forums in .pdf form as a freely available update to the book... if you search for his book you can find at least this short .pdf, and it's the very last paragraph of that .pdf..... not that you need all this info. just giving proper reference...)

In summary, you can't get the exact decimal precision you want(Max6 is sort of a transitional stage, in the future, everything will probably be 64-bit and you'll get more precision then... whether it's the amount of precision you'll need may always be an issue... but i think 8 decimal places would be possible then, reliably so...).
You can multiply by 1000 if you are willing to work constantly at that multiplication. As soon as you attempt to convert back by a divide or similar, it'll drop the same decimal places where it dropped before.

I guess my next question the - if I get my learn on with regular expressions, would I be able to create something that can keep track of the * 1000 and move the decimal place accordingly when I get to the final sequence stage of my device?

So say 0.00111111 gets turned into 11.111111, I can somehow tell my zl queue to move that decimal point to the left 4 times in the queue order?

Here is the part that converts it into individual parts - if I use quotations in a message it works fine, so I'm wondering if there's some way to send flonum directly to a messagebox in quotes (fromsymbol still strips it)

I think you're talking about treating the numbers as symbols and moving the decimal place more like a character within a word? (edit: sorry, you answered this in your last post, but didn't see that til after i wrote this one)

If so, i imagine it's possible as long as you're not dealing with it like a number...

If, however, you try to use 0.00111111 as a number at any point, it will be truncated again when passed as a message through the max environment.

Here's a patch that sort of shows how you could treat a number as a symbol, but as soon as a max object attempts to send it out of its outlet as a number, it will truncate again:

The only real solutions i could recommend is either trying to send it to an external app of some sort that could keep the precision you want, or try to work the math entirely in the signal-domain(probably too cpu-expensive though), or possibly write your own external in C that would do everything 64-bit internally(the problem here is really the passing of messages between max objects... always truncated to 32-bit when passing a number from one max non-signal object to another).

I think you're talking about treating the numbers as symbols and moving the decimal place more like a character within a word? (edit: sorry, you answered this in your last post, but didn't see that til after i wrote this one)
If so, i imagine it's possible as long as you're not dealing with it like a number...
If, however, you try to use 0.00111111 as a number at any point, it will be truncated again when passed as a message through the max environment.

The only real solutions i could recommend is either trying to send it to an external app of some sort that could keep the precision you want, or try to work the math entirely in the signal-domain(probably too cpu-expensive though), or possibly write your own external in C that would do everything 64-bit internally(the problem here is really the passing of messages between max objects... always truncated to 32-bit when passing a number from one max non-signal object to another).


the way I see it there should be no problem in simply constantly working in * 1000, or even * 1000000, as long as you divide down later on - and you can easily do that at the end of the line... but perhaps you don't even need to divide down? I mean, you're doing midi representation of the data, it doesn't care if it's 0.0001111 or 1111, really.

the way I see it there should be no problem in simply constantly working in * 1000, or even * 1000000, as long as you divide down later on - and you can easily do that at the end of the line... but perhaps you don't even need to divide down?  I mean, you're doing midi representation of the data, it  doesn't care if it's 0.0001111 or 1111, really.


this is not true. max 6 in 64 bit mode can send double precision floats between objects.

it's easy to verify that, e.g. with the following test.

compare the results in 32-bit and 64-bit mode.

Unfortunately, Max floating point messages are still 32-bit floating-point(even though Max6 is a 64-bit app and runs 64-bit audio).
This means objects can compute with 64-bit precision, but when sending regular max floating-point messages between objects, those messages will always be 32-bit floating points.

this is not true. max 6 in 64 bit mode can send double precision floats between objects.
it's easy to verify that, e.g. with the following test.
compare the results in 32-bit and 64-bit mode.


^i saw the above before, but forgot to say Thank You, Volker!

(i am indeed an ignoramus about my versions, and was still going by the update .pdf to the book...)

^i saw the above before, but forgot to say Thank You, Volker!
(i am indeed an ignoramus about my versions, and was still going by the update .pdf to the book...)
test-patch much appreciated, too.


Gold full node client with signed prebuilt binaries is available ?

 Is Bitcoin Gold full node client with signed prebuilt binaries is available ?

Looking for a workaround for long decimal places being stripped.