Porting a PD Patch with Scientific Notation to Max? [IMG]

srs's icon

Hi - I'm trying to port a PD patch by the venerable Andy Farnell and have run into a situation where a calculation using scientific notation is required and the resulting sound output is massively different - does anyone know if Max can handle numbers in the billions / billionths?

I'm guessing this is the cause as all the other object have decent enough equivalents (right?)

Attached are both the pd and max versions. The arguments $1 and $2 are 3 and 0.008 respectively and what the patch is meant to do is create a very sharp stuttering effect used in the modelling of electricity.

The PD version perfectly cuts the audio but the max version just sounds like bad distortion.

For anyone else interested in this - the pd src and audio is here

(the tarbull in the top left has all the examples)

Thanks

3566.randgatemax.png
png
big_pause's icon
Max Patch
Copy patch and select New From Clipboard in Max.

Try multiplying by a float, what you're getting is integer overflow e.g.

srs's icon

Thanks for the reply - I'd never heard of integer overflow. It's weird how in your patch there are a few numerical artifacts even when multiplying by a float between 0. and 1. (e.g. 0.521)

I also changed clip~ to use floats but strangely enough, neither change affected the sound output of the patch - its still just distortion and quite different to the pd version.

Hard to see where else the problem could be unless lop~ is significantly different to lores~?

srs's icon

UPDATE:

Turns out the equivalent of the PD object lop~ is onepole~, not lores~.

Max Patch
Copy patch and select New From Clipboard in Max.

For anyone else interested - below is the patch that sounds almost the same as the PD version.

3567.randgatemaxv2.png
png
big_pause's icon

the artefacts you notice, are down to floating point representations.

Peter Castine's icon

@big_post: Although the difference between ints and floats is significant the the Max world, in MSP everything is float. Always.

Artefacts being caused by floating point representation is, as you rightly point out, another gotcha. In the patch in question these might be slightly minimized by combining the two multiplications [*~ 0.0008] -> [*~ 1000000000] into a single object [*~ 800000]. (Double check those zeros). With 32 bit floats you have a 24 bit mantissa which limits accuracy to about 6 digits.

Alternately, on Max 6 with 64-bit floats you've got a 53-bit mantissa, ie accuracy to 13 decimal digits. That ought to get this patch through the night.

big_pause's icon

@peter, you are of course right, and I need to stop skim reading (bad habit) ....