and you're only talking about the aesthetical/workflow features. to
bring up
a subject that I am paying attention only now, try out to see how high
you go
with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in
max5
(the coming up of Pd double precision will help this, but it's a work
Katja
is doing alone).
There's a big difference between decimal precision as printed on screen
and in text files and [netsend], and binary precision used in most other
situations.
Pd is able to think of numbers bigger than a million, but won't print a
million plus one. It is able to if you force it to, using less than ideal
tools such as [makefilename] that creates one symbol each time, or
[#sprintf] that makes you a float list of ascii codes.
Neither binary nor decimal representation is more precise than the other,
it's just that their precision never matches exactly. 20 bits is slightly
less than 6 decimals, whereas 16 decimals is slightly more than 53 bits.
Thus you can only preserve precision by using slightly too many digits,
otherwise you'll have too few.
I don't know what max5 does, but the only practical float sizes in the
main processor are 24 bits and 53 bits. (this assumes that the most
significant bit is not recorded because it's always one)
Which means, for example, in max you have more resolution than Pd to
control
the playback of large arrays with precision (up to 2147483647,
that's 31 bits. From 0 to 2147483647, you have 2147483648 numbers, which
is pow(2,31) exactly (aka 1<<31), if it didn't overflow. the 32nd bit is
the sign. That's using integers. I bet that you can't have integer
signals. Can you ? Otherwise, you're stuck at the same limit as Pd...
though Pd42 does offer a workaround as a 2nd inlet in [tabread~].
Does Max offer that 2nd inlet ?
don't know, can't even find out which object corresponds to tabread4~
BTW : in floats, pd can exactly represent powers of two up to pow(2,127).
Powers of two are represented exactly in binary. They just won't be
printed exactly in decimal by default, but [makefilename %f] can print
«symbol 170141183460469231731687303715884105728.000000» accurately. The
float format stops working just before getting to pow(2,128). But for
[tabread~] you need contiguous integers, and that stops at 16777216, and
for [tabread4~] you need at least some fractions to make it useful at all
(contiguous sixteenths stop at 1048576, for example). So, your power-of-2
example is misleading in another way.
I already have an abstraction in pd to automatically set the offset to
play segments with tabread4~. But if I need e.g. to play indices 100000000
to 100000111, which are read from an array, and then rescaled in the
meantime, how is it possible to keep precision using symbol-tricks? The
2nd inlet doesn't help me much, if the numbers going inside are still
wrong.
Or, a concrete question: my table has 15312000 samples (5m19s@48K). You
mean that if I want to play from index 15311000 to 15312019, (these values
are read from a file and stored in an array, and also quantized in the
way), the precision will be correct, just will be printed wrongly in the
atom boxes?
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
