as for now I think I can count up to 16 777 216. correct? ok, I can live with that for the moment. m.
marius schebella wrote:
that's the problem with floats... another question I have is, how high is it possible to count without problems?
Indexing tables with very big sizes is one place I've seen the precision limitations come up in Pd. If you index a huge sound file with a slow moving phasor you will hear tiny jumps as it gets further and further into the array.
marius.
IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, thomas thiery hat gesagt: // thomas thiery wrote:
hello, I have just seen me a bug under pure data but I do not manage to explain it. The problem comes from the int's box, I believe. I think that you know it already. Here my patch
Hm, I don't really see what should be the bug in this patch?
roll to 41
mfg.asdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
padawan12@obiwannabe.co.uk wrote:
Indexing tables with very big sizes is one place I've seen the precision limitations come up in Pd. If you index a huge sound file with a slow moving phasor you will hear tiny jumps as it gets further and further into the array.
you're right, with my calculation (16777216) with sr=44.100 Hz that affects every table greater than 6min20sec??? m.
On Mon, 11 Dec 2006, marius schebella wrote:
padawan12@obiwannabe.co.uk wrote:
Indexing tables with very big sizes is one place I've seen the precision limitations come up in Pd. If you index a huge sound file with a slow moving phasor you will hear tiny jumps as it gets further and further into the array.
you're right, with my calculation (16777216) with sr=44.100 Hz that affects every table greater than 6min20sec???
With [tabread] and [tabread~] only: with [tabread4] it's actually much worse, because above half of that value they can't do interpolation, and even for values lower than that they can't get to the precision that might be required for proper antialiasing.
IMHO this is fixable by introducing either 64-bit floats in place of 32-bit floats, or by introducing a dual system in which 32-bit floats coexist (32 or high performance, 64 for high precision). The latter is more work, but it's better because you wouldn't need to have separate executables for high speed pd vs high precision pd (and all DSP externals need to be recompiled differently to be compatible with a 64-bit-only pd)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
marius schebella -
Mathieu Bouchard -
padawan12＠obiwannabe.co.uk