• ### rpole~ and single precision floating point

I made a trippy oscilloscope graphics patch that does its thing when driven by a sweeping sine wave and was hoping to sweep from 0 to 22050 hz at variable rates in order to pass more quickly over the boring parts. So I thought I'd just accumulate the frequency signal using rpole~ and vary the left inlet (i.e. the increment for each sample period). Well the whole patch froze when the frequency reached 256, and I thought it must be due to trying to add such a small increment (10 millionths) to a relatively large number 256 (large in single precision floating point terms). Not the dumbest conclusion to jump to, right? There are about 8 decimal digits between the increment and the max value.

So I remember reading about "onset" in the tabread4~ help file, and thought maybe I could do something similar. Problem is that it's not behaving as expected. As you can see in my test patch, when the next onset is snapshotted, the slope changes. I turned off DSP after the left rpole~ maxed out at 256, when the right one had only gotten to 254.5! I can't explain that at all, except to suspect that it has something to do with the boundaries of single precision floating point that I don't understand. So I've provisionally decided that there's no way to write a Pd vanilla patch to do what tabread4~ does with onset because no matter what you do, you're stuck with single precision floating point arithmetic. Agree?
rpole~ and single precision float.pd

PS: line~ has similar issues. Try slewing from 256 to 257 over a minute and see what it does. A total head-scratcher.
line~ weirdness.pd
Update: it works better if you slew [line~] from 0 to 1 over a minute and add 256.

• Posts 3 | Views 227
• @jameslo yeah, `[tabread4~]` and I think `[rpole~]` add up numbers internally as doubles, whereas `[+~ ]` obviously has to output as 32-bit since that's the bit depth of float messages and signals in patch cords
edit: the reason `[line~]` misbehaves as well is because it also uses 32-bit floats internally (and because it just stores the "increment" to use every sample, and that might be truncated). `[vline~]` uses doubles though

• @seb-harmonik.ar Why is interest in double-precision floats so weak? All the discussion/documentation of it I've found is very old.

Posts 3 | Views 227
Internal error.

Oops! Looks like something went wrong!