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.
