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

Ok, Matt Barber explained to me how has this doesn't really work and I was just fooled... I couldn't hear it with a sine tone but some of the samples were being repeated. I was checking a table up to 10 minutes.

Nonetheless, an object like tabplay~ can read up to 10 minutes just fine and I guess an external that takes a speed/rate parameter and an index could be a nice alternative to not worry about the workaround from "b16". Actually, it'd be good if such an object could be part of vanilla... one way or another, I'm now working on a tabplayer~ external for "ELSE" to do this trick.

but then, with Pd compiled for 64 bits becoming an inevitable reality any time soon, maybe we could just forget about it?

cheers

Em sex., 25 de set. de 2020 às 02:22, Alexandre Torres Porres < porres@gmail.com> escreveu:

Howdy;

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?

Cheers