[PD] b16.long-varispeed working? bypass the "onset" solution?
Alexandre Torres Porres
porres at gmail.com
Fri Sep 25 07:22:32 CEST 2020
First, I'm not sure what I'm supposed to hear in the example
b16.long-varispeed or if it ain't working - I don't really get the example
either so I can't say.
Now, it seems the limit to tabread4~ is indexes up to 2ˆ24 and no Pd
vanilla patch can count over that, right? I tried [fexpr~ $x + $y] with an
input/increment of 1 and it stops at 2ˆ24 for instance. I also couldn't do
it with +~ and a feedback delay with block size of 1.
But.......... I have [else/ramp~] and it has an internal "sum" variable
which is a 'double', and I see it works just great to generate indexes over
that limit and [tabread4~] gets those values alright! I'm on macOS using
0.51-2, downloaded from miller's website (that is a 64bit binary, not the
32 one, but not Pd compiled with float = 64 bits, got it?).
Anyway, so, should I be aware that else/ramp~ may not work in some cases
(maybe the 32 bit mac binary provided by miller)? Why can't we have [expr~]
with a 'double' variable that can count over the 2ˆ24 limit and not worry
about (or "bypass") the "onset hack" of example b16?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list