[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...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200925/c30df3c3/attachment.html>

More information about the Pd-list mailing list