Forums > MaxMSP

itable

May 11, 2009 | 7:11 pm

Hi,

I’m using the itable to store durational values.. ie divisions of a global tempo. As the majority of these values are floating point numbers (which are necessary if the divisions of a global duration are to be exact), I have a problem because once they are input into the itable they are converted into integers – it seems this object doesn’t store floats. As I have these then read out to dynamically change the output of a metro object (to sync in with the an initial metro beating the global tempo), I need these floats otherwise the synchronisation is not exact.

Any idea if itable or table are able to store and output floating point numbers? Or any suggestions on how to get around this issue??

Thanks in advance.


May 11, 2009 | 7:22 pm

The helpfile and refpage are always the court of last resort – the itable object works with integers only. There really aren’t any secrets that are not in the stuff that comes online with Max.

You can always multiply your floating values by some power of 10 before you store the data and then divide by the same value when you fetch the data. That’s what most people do.


May 11, 2009 | 7:24 pm

You can store floats in a buffer using peek. But I wouldn’t count too much on float precision timing of a metro. Such precision might be achieved in the audio domain, eg with zigzag~, a bit depending on your application. A midi file however is able to store fractional tempos in integer values. You might also want to have a look at that.

_
johan


May 11, 2009 | 7:25 pm

You should be able to use [multislider] in a similar way; it can store floating point values.

lh


May 11, 2009 | 7:30 pm

thanks very much for the info everyone.. i’ll check these out tonight.

cheers


May 12, 2009 | 5:13 pm
Gregory Taylor wrote on Mon, 11 May 2009 21:22
You can always multiply your floating values by some power of 10 before you store the data and then divide by the same value when you fetch the data. That’s what most people do.

Although popular, there are problems with powers of 10. Dividing by a power of 10 will run into the precision issues that lead to one of the perennial frequently asked questions on this board. (Briefly, with computer arithmetic 10.0*0.1 is almost never one.) Using powers of 2 will avoid those precision issues.

Also, you probably want to round when converting to an integer value.

If you’re not too worried about precision, though, powers of 10 will do fine.


Corrected stupid typo.


May 12, 2009 | 6:54 pm

Thanks for the tip Peter… in fact for this problem I’ve found a way to implement it using lh’s suggestion of a multislider… and it’s working a treat for now. I’ll definitely keep this in mind for future problems..

Cheers again.


Viewing 7 posts - 1 through 7 (of 7 total)